Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Parties with role ParticipantRegistry can add new parties in the role of data service rights holder and legal data service consumer to the DSGO central participant registry with a POST to the /parties endpoint.
The central participant registry MUST support a POST call to a /parties endpoint.
Request
Authorization
An access token is used in POST calls to the /parties endpoint. For more information, see Access Token.
The central participant registry MUST validate that a POST call to a /parties endpoint includes the “Authorization" header according to RFC 6750 and includes a valid access token
The central participant registry MUST validate that the HTTP body of a POST request to the /parties endpoint contains the attributes as defined in the table below, formatted as JSON
Array with other identifiers of the party. Each identifier includes a prefix and must be an unique organisation ID, for example kvk:98765432, eori:EU.EORI.NL000123456
name
Required
String
MUST be equal to the organisation name as registered at the Chamber of Commerce.
If successful, the response contains data providing the created party information in a partyToken. The partyToken is a signed JWT, which contains the claims as defined in the iSHARE JWT, and additionally contains a partyInfo object as defined here.
The trust framework catalogue MUST include a partyToken including a partyInfo object in a response to a successful POST call to the /parties endpoint
The PartyInfo object in a response to a successful POST call to the /parties endpoint contains no claims, i.e. has an empty array for claims
When Authorization header is provided, but the token format is invalid (for example, not Bearer). Additionally, a 400 should be returned when the provided access token is valid, but the request body content is invalid.
401 Unauthorized
When Authorization header is either missing, invalid or the access token has already expired.
403 Forbidden
When client is authenticated but not allowed to perform the action