Propose Attributes to peer
An Identity may have received information about a peer in the past that it needs to process a transaction at a later time. To ensure the accuracy of the available information, the Identity can propose Attributes to the peer for creation. Depending on whether the peer confirms the fittingness of a proposed Attribute, it can agree to its creation or correct the Attribute value beforehand. Proposing Attributes to a peer can be useful in these and many other situations, such as:
- An organization supports an Identity in setting up an enmeshed account by proposing Attributes to it that was derived from the organization’s knowledge about the Identity.
- A company wants to make sure that the currently stored street address of a customer is valid before using it to ship an item to the customer.
We will now explain how a Connector, hereinafter referred to as the Sender, can propose an Attribute to another Connector, the so-called Recipient. Since understanding this proposing process requires knowledge about Requests and how to use them in general, you should take a look at our Request and Response introduction before continuing reading this guide.
Please note that the general procedure is the same if the Connector wants to propose an Attribute to an App user instead of another Connector. For reasons of clarity, this guide focuses on the proposing process with two Connectors.
Request for proposing Attributes
The Sender wants to propose an Attribute to the Recipient. To do this, the Sender must first create a suitable Request, which it can then send to the Recipient. In the following subsections, we describe the general appearance of a Request for proposing Attributes.
Role of ProposeAttributeRequestItem
To propose a single Attribute to the Recipient, a single RequestItem of type ProposeAttributeRequestItem must be inserted into the items
property of the Request. It is possible to propose an IdentityAttribute or a RelationshipAttribute, which must be inserted into the attribute
property of the ProposeAttributeRequestItem. As it only makes sense for the Sender to propose an Attribute to the Recipient which is owned by the Recipient, the Sender must specify an empty string as the value for the owner
property of the Attribute. The Recipient automatically becomes the owner of the Attribute later on. As the Recipient may want to change the Attribute value of the proposed Attribute, the Sender must formulate a query
matching the attribute
. If the Sender specifies an attribute
and a query
that are incompatible, an error with the code error.runtime.requestDeserialization
or with the code error.consumption.requests.attributeQueryMismatch
is to be expected.
Combinations and usage scenarios of ProposeAttributeRequestItem
The following table provides an overview of the possible kinds of Attributes that the Sender can propose to the Recipient using the ProposeAttributeRequestItem. It must be taken into account whether the Attribute is an IdentityAttribute or a RelationshipAttribute and that its owner
must be the Recipient, which is why the Sender must always specify an empty string as the value for the owner
property of the Attribute contained within the attribute
property of the ProposeAttributeRequestItem. If a RelationshipAttributeQuery is used as the query
of the ProposeAttributeRequestItem, an empty string must also be specified as the value for its owner
property. A ProposeAttributeRequestItem can only be used to propose the creation of RelationshipAttributes that exist in the context of the Relationship between the Sender and the Recipient.
Type and context | Owner | Possible? | Automation | Remarks, reasons and examples |
---|---|---|---|---|
IdentityAttribute | Sender | ✗ | N/A |
It makes no sense for the Sender to propose IdentityAttributes to the Recipient that are owned by itself. Using the ShareAttributeRequestItem is appropriate instead. For more details, the Share Attributes with peer scenario documentation can be consulted. |
IdentityAttribute | Recipient | ✓ | USER_DECISION |
Example: A company sends the name and the address of a new customer to them during their onboarding process. |
RelationshipAttribute that exists in the context of the Relationship between the Sender and the Recipient | Sender | ✗ | N/A |
It makes no sense for the Sender to propose RelationshipAttributes to the Recipient that are owned by itself. Instead, it is appropriate to proceed as described in the documentation of the Create Attributes for peer or Read Attributes from peer scenario and use the CreateAttributeRequestItem or the ReadAttributeRequestItem, respectively. |
RelationshipAttribute that exists in the context of the Relationship between the Sender and the Recipient | Recipient | ✓ | USER_DECISION |
With this combination, the Sender gives the Recipient the one-time permission to create a RelationshipAttribute, which is owned by the Recipient, with the Sender proposing a value for it as default option that might make sense. |
Example of proposing an IdentityAttribute
In the case in which the Sender wants to propose an IdentityAttribute to the Recipient, it must use a ProposeAttributeRequestItem which contains the IdentityAttribute in its attribute
property and a matching IdentityAttributeQuery in its query
property. This means that the specified value for the valueType
property of the IdentityAttributeQuery must correspond to the Attribute value type of the IdentityAttribute. The ProposeAttributeRequestItem must then be inserted into the items
property of the Request for proposing Attributes. For example, the Sender wants to propose an IdentityAttribute of type EMailAddress to the Recipient. The value of the mustBeAccepted
property of the ProposeAttributeRequestItem is set to true
in our example and the <...>
notation is used as a placeholder for the actual data as usual.
{
"@type": "Request",
"items": [
{
"@type": "ProposeAttributeRequestItem",
"mustBeAccepted": true,
"attribute": {
"@type": "IdentityAttribute",
"owner": "",
"value": {
"@type": "EMailAddress",
"value": "<email address that the Sender proposes to the Recipient>"
}
},
"query": {
"@type": "IdentityAttributeQuery",
"valueType": "EMailAddress"
}
}
]
}
It is also possible to use an appropriate IQLQuery instead of an IdentityAttributeQuery as the query
when proposing an IdentityAttribute with a ProposeAttributeRequestItem.
Example of proposing a RelationshipAttribute
Let’s consider the case in which the Sender has established an active Relationship with the Recipient and the Sender wants to propose a RelationshipAttribute for this Relationship to the Recipient. Then the Sender needs to insert a corresponding ProposeAttributeRequestItem, which contains the RelationshipAttribute in its attribute
property and a matching RelationshipAttributeQuery in its query
property, into the items
property of the Request for proposing Attributes. In particular, it is necessary that the specified value for the attributeCreationHints.valueType
property of the RelationshipAttributeQuery corresponds to the Attribute value type of the RelationshipAttribute. For example, the Sender wants to propose a RelationshipAttribute of type ProprietaryString to the Recipient whose confidentiality
is "public"
, whereby the value of the mustBeAccepted
property of the associated ProposeAttributeRequestItem is set to true
.
{
"@type": "Request",
"items": [
{
"@type": "ProposeAttributeRequestItem",
"mustBeAccepted": true,
"attribute": {
"@type": "RelationshipAttribute",
"owner": "",
"key": "<key of RelationshipAttribute>",
"confidentiality": "public",
"value": {
"@type": "ProprietaryString",
"title": "<title of RelationshipAttribute>",
"value": "<actual value of RelationshipAttribute that the Sender proposes to the Recipient>"
}
},
"query": {
"@type": "RelationshipAttributeQuery",
"key": "<key of RelationshipAttribute>",
"owner": "",
"attributeCreationHints": {
"title": "<title of RelationshipAttribute>",
"valueType": "ProprietaryString",
"confidentiality": "public"
}
}
}
]
}
Propose multiple Attributes
Proposing Attributes to a peer is not limited to just a single Attribute, but it is possible to propose multiple Attributes to a peer at the same time. For this purpose, several ProposeAttributeRequestItems or suitable RequestItemGroups can be inserted into the items
property of the Request for proposing Attributes. If you want to use a RequestItemGroup in order to propose multiple Attributes to the Recipient at the same time, you must insert corresponding ProposeAttributeRequestItems into the items
property of it.
Send and receive the Request
The Sender that wants to propose an Attribute to the Recipient may or may not already have a Relationship with the Recipient. Depending on which is the case, a different method can be used to send the Request for proposing Attributes. There are two ways to send the Request for proposing Attributes created by the Sender to the Recipient.
Request via RelationshipTemplate
If there is currently no Relationship between the Sender and the Recipient, this approach must be used. However, it is also possible for the Sender to use a RelationshipTemplate to send a Request to the Recipient if there is already an active Relationship between them. All details on how to send and receive a Request via a RelationshipTemplate in general can be found in the Requests via RelationshipTemplates guide.
Request via Message
The Sender only has the option of sending a Request to the Recipient via a Message if there is already an active Relationship between them. All information on how to send and receive a Request via a Message can be found in the Requests via Messages guide.
Accept the Request and deal with the proposed Attributes
After the Recipient has received the Request for proposing Attributes, it can accept it to create all or some of the Attributes that were proposed for creation by the Sender. The Recipient also has the option of overwriting the Attribute values beforehand or sending existing Attributes back to the Sender instead of creating new ones. To accept the Request, proceed as described in the Accept incoming Request use case documentation and specify the id
of the received Request. Also, you need to decide and specify for each ProposeAttributeRequestItem contained in the Request for proposing Attributes whether you want to accept or reject it.
If the Recipient does not want to deal with any of the Attributes proposed by the Sender and, therefore, does not want to accept the Request for proposing Attributes of the Sender, it can reject it as a whole as well. For that, follow the instructions of the Reject incoming Request use case.
Accept a ProposeAttributeRequestItem
The Recipient can accept a ProposeAttributeRequestItem contained in the Request for proposing Attributes using an appropriate AcceptProposeAttributeRequestItemParameter. Depending on whether the Recipient confirms the fittingness of the associated proposed Attribute, it can agree to its creation and send it back to the Sender unchanged or correct the Attribute Value beforehand. To do this, the Recipient needs to specify the proposed Attribute or an Attribute that differs from the proposed Attribute only by the Attribute value as the value for the attribute
parameter of the AcceptProposeAttributeRequestItemParameters. As it makes no sense for the Sender to request a RelationshipAttribute from the Recipient that already exists in the context of their Relationship to each other, a RelationshipAttributeQuery that is potentially specified in the query
property of the ProposeAttributeRequestItem can only be validly answered by the Recipient with a new Attribute.
If the Recipient does not want to create a new Attribute, it can alternatively send an existing Attribute back to the Sender. The attributeId
parameter of the AcceptProposeAttributeRequestItemParameters must be used for that. The existing Attribute may only differ from the proposed Attribute by its Attribute value. The acceptance of a ProposeAttributeRequestItem leads to the creation of a corresponding LocalAttribute with a LocalAttributeShareInfo contained within its shareInfo
property. The content
of the LocalAttribute is the Attribute that the Recipient wants to send back to the Sender. Depending on whether the Recipient confirms the fittingness of the proposed Attribute, it is therefore the proposed Attribute itself or a corrected version of it.
If the Recipient accepts with a new Attribute or an existing one that isn’t shared with the peer already neither itself nor any of its predecessing versions, an appropriate AcceptResponseItem of type ProposeAttributeAcceptResponseItem will be generated.
It incorporates the id
of the LocalAttribute with the LocalAttributeShareInfo in its attributeId
property and the Attribute that the Recipient wants to send back to the Sender in its attribute
property.
If a new IdentityAttribute is to be created and sent back to the Sender, a corresponding LocalAttribute without a LocalAttributeShareInfo is additionally created for the Recipient beforehand.
If the ProposeAttributeRequestItem is accepted with an existing Attribute that the Recipient already shared with the Sender, an AttributeAlreadySharedAcceptResponseItem will be generated, given that the own shared LocalAttribute doesn’t have "DeletedByPeer"
or "ToBeDeletedByPeer"
as deletionInfo.deletionStatus
.
Instead of creating a further own shared/peer shared Attribute pair, the id
of the already existing shared LocalAttributes is returned.
Note that the id
of the shared Attribute of the Sender matches the id
of the corresponding shared Attribute of the Recipient.
Lastly, if the ProposeAttributeRequestItem is accepted with an existing Attribute of which the Recipient already shared a predecessor with the Sender, an AttributeSuccessionAcceptResponseItem will be generated, given that the own shared predecessor doesn’t have "DeletedByPeer"
or "ToBeDeletedByPeer"
as deletionInfo.deletionStatus
.
Instead of creating an independent own shared/peer shared Attribute pair, internally an Attribute succession is performed.
The id
of the already existing shared LocalAttribute predecessor is returned, as well as the id
and content
of the newly created successor.
When the Sender of the Request receives the AttributeSuccessionAcceptResponseItem, the according succession is automatically performed for them.
In any case, the respective AcceptResponseItem will be included in the items
property of the Response to the Request for proposing Attributes that will be transferred to the Sender.
Otherwise, the error code error.consumption.requests.invalidAcceptParameters
arises. Furthermore, an error with the code error.consumption.requests.attributeQueryMismatch
is thrown if the Attribute provided by the Recipient does not match the AttributeQuery specified in the query
property of the ProposeAttributeRequestItem.
The acceptance of a ProposeAttributeRequestItem leads to the creation of a corresponding LocalAttribute with a LocalAttributeShareInfo contained within its shareInfo
property. The content
of the LocalAttribute is the Attribute that the Recipient wants to send back to the Sender. Depending on whether the Recipient confirms the fittingness of the proposed Attribute, it is therefore the proposed Attribute itself or a corrected version of it. Based on this LocalAttribute, an appropriate AcceptResponseItem of type ProposeAttributeAcceptResponseItem is generated, which incorporates the id
of the LocalAttribute with the LocalAttributeShareInfo in its attributeId
property and the Attribute that the Recipient wants to send back to the Sender in its attribute
property. This ProposeAttributeAcceptResponseItem will be contained within the items
property of the Response to the Request for proposing Attributes that will be transferred to the Sender. If a new IdentityAttribute is to be created and sent back to the Sender, a corresponding LocalAttribute without a LocalAttributeShareInfo is additionally created for the Recipient beforehand.
It is noticeable that accepting a ProposeAttributeRequestItem essentially works in the same way as accepting a ReadAttributeRequestItem. Both types of RequestItems are used when an Identity needs information from a peer. The difference between the two RequestItems is that when using the ProposeAttributeRequestItem, the Identity not only asks for an Attribute of a certain Attribute value type, but also proposes a specific Attribute to the peer for creation that might be suitable. The ProposeAttributeRequestItem can therefore also be understood as a combination of the ReadAttributeRequestItem and the CreateAttributeRequestItem. To gain a deeper understanding of these connections, take a look at the Read Attributes from peer guide and the Create Attributes for peer guide.
Reject a ProposeAttributeRequestItem
Even if the Recipient accepts the Request for proposing Attributes as a whole, it may decide not to accept all of the ProposeAttributeRequestItems it contains. To be more precise, the Recipient has the option of rejecting ProposeAttributeRequestItems that have the value false
specified in their mustBeAccepted
property. To reject a ProposeAttributeRequestItem, use the RejectRequestItemParameters. The rejection of a ProposeAttributeRequestItem leads to the creation of a corresponding ResponseItem of type RejectResponseItem. This will be contained within the items
property of the Response to the Request for proposing Attributes.
Example of accepting a RequestItemGroup
Let’s look at an example where the Sender proposes the Recipient’s PersonName and contact information in the form of an EMailAddress and a PhoneNumber to the Recipient during its onboarding process. For this purpose, the Sender creates a Request for proposing Attributes, which contains a ProposeAttributeRequestItem belonging to the PersonName and a RequestItemGroup belonging to the contact information in its items
property. The RequestItemGroup itself includes two ProposeAttributeRequestItems in its items
property, namely one for the EMailAddress and one for the PhoneNumber.
{
"@type": "Request",
"items": [
{
"@type": "ProposeAttributeRequestItem",
"mustBeAccepted": true,
"attribute": {
"@type": "IdentityAttribute",
"owner": "",
"value": {
"@type": "PersonName",
"givenName": "<given name that the Sender proposes to the Recipient>",
"surname": "<surname that the Sender proposes to the Recipient>"
}
},
"query": {
"@type": "IdentityAttributeQuery",
"valueType": "PersonName"
}
},
{
"@type": "RequestItemGroup",
"items": [
{
"@type": "ProposeAttributeRequestItem",
"mustBeAccepted": true,
"attribute": {
"@type": "IdentityAttribute",
"owner": "",
"value": {
"@type": "EMailAddress",
"value": "<email address that the Sender proposes to the Recipient>"
}
},
"query": {
"@type": "IdentityAttributeQuery",
"valueType": "EMailAddress"
}
},
{
"@type": "ProposeAttributeRequestItem",
"mustBeAccepted": false,
"attribute": {
"@type": "IdentityAttribute",
"owner": "",
"value": {
"@type": "PhoneNumber",
"value": "<phone number that the Sender proposes to the Recipient>"
}
},
"query": {
"@type": "IdentityAttributeQuery",
"valueType": "PhoneNumber"
}
}
]
}
]
}
In our example, the Sender only requires the Recipient to accept the ProposeAttributeRequestItems belonging to the PersonName and the EMailAddress, which is why the individual ProposeAttributeRequestItems within the Request have specified corresponding values in their mustBeAccepted
property. We assume that the Recipient wants to accept the Request and all its ProposeAttributeRequestItems with the exception of the PhoneNumber.
If the Recipient wants to accept the Request for proposing Attributes, it must accept all ProposeAttributeRequestItems for which the mustBeAccepted
property is set to true
. It is therefore not permitted for the Recipient to refuse to accept the ProposeAttributeRequestItem belonging to the PersonName or the EMailAddress.
We assume that the Recipient confirms the fittingness of the PersonName proposed by the Sender and that the Sender has proposed an outdated EMailAddress to the Recipient for creation. The Recipient therefore wants to create a corrected version of the EMailAddress and send it back to the Sender. The Recipient accepts at least one ProposeAttributeRequestItem of the RequestItemGroup, rejects the PhoneNumber and accepts the ProposeAttributeRequestItems belonging to the PersonName and the EMailAddress. Consequently, it responds to the Request for proposing Attributes as follows:
{
"items": [
{
// Accept the creation of the proposed PersonName
"accept": true,
"attribute": {
"@type": "IdentityAttribute",
"owner": "<address of Recipient>",
"value": {
"@type": "PersonName",
"givenName": "<given name that the Sender proposes to the Recipient>",
"surname": "<surname that the Sender proposes to the Recipient>"
}
}
},
{
"items": [
{
// Create a corrected version of the proposed EMailAddress
"accept": true,
"attribute": {
"@type": "IdentityAttribute",
"owner": "<address of Recipient>",
"value": {
"@type": "EMailAddress",
"value": "<Recipient's corrected version of the email address>"
}
}
},
{
// Reject PhoneNumber
"accept": false
}
]
}
]
}
Note that it is important to respond to RequestItems, some of which may be contained in a RequestItemGroup, in the same order in which they were received.
Receive the Response to the Request
We now assume that the Recipient has accepted the Request for proposing Attributes of the Sender. In order for the Sender to receive the Response of the Recipient, it needs to synchronize the updates of the Backbone. Please note that this synchronization can also be automated by using the Sync Module.
To view the Response to the Request, search for it in the synchronization result or proceed as described in the Query outgoing Requests use case documentation and use the following query parameter:
- If the Request was sent via a RelationshipTemplate: Specify
<ID of RelationshipTemplate>
as the value for thesource.reference
query parameter. - If the Request was sent via a Message: Specify
<ID of Request>
as the value for theid
query parameter.
The Integrator of the Sender can now get the Response of the Recipient from the response.content
property of the result. In the items
property of the Response is a ProposeAttributeAcceptResponseItem for each accepted ProposeAttributeRequestItem and a RejectResponseItem for each rejected ProposeAttributeRequestItem included. Note that each accepted ProposeAttributeRequestItem leads to the creation of an appropriate LocalAttribute with a LocalAttributeShareInfo of the Sender. The content
of the LocalAttribute is the Attribute that the Recipient has sent back to the Sender. Depending on whether the Recipient has confirmed the fittingness of the Attribute proposed by the Sender, it is therefore the proposed Attribute itself or a corrected version of it.
In case of an error, ErrorResponseItems can also be included in the Response. If the Request for proposing Attributes contains a RequestItemGroup in its items
property, the Response to this Request contains a corresponding ResponseItemGroup in its items
property.
What’s next?
An Identity has several options for requesting an Attribute creation. This guide covers how an Identity can request the creation of an Attribute for a peer so that the Attribute value is proposed by the Identity, but can be modified by the peer when accepting the Request. In some cases, it makes more sense if the peer cannot change the proposed Attribute value. For that, take a look at the Create Attributes for peer guide.