Documentation defect in the non-normative example - DH calling the DR Revocation Endpoint

[CDR-AMO]

Description

For a DH calling the DR Revocation endpoint the non-normative examples provided in the Client Authentication section includes a Bearer Token for authorization as below .

POST https://data.recipient.com.au/revocation HTTP/1.1
Host: data.recipient.com.au
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey

However, for both DH and DR revocation endpoints, Client Authentication is the only requirement and no bearer token is needed in the authorization header as detailed in the Revocation Endpoints section .

The documentation needs to be corrected accordingly to use client_assertion instead of a bearer token.

[pcurtisrab]

Regional Australia Bank would like to note that we read the Consumer Data Standard as complete and consistent in this regard.

The Revocation Endpoints section indeed states the use of Client Authentication. However, Client Authentication takes different forms depending on who is the sender and receiver of the request. For example:

• DR calling DH revocation endpoint uses the client_id, client_assertion JWT POST body parameters.
• DH calling DR revocation endpoint supplies the JWT as a bearer token.

Both forms come under the heading of the Client Authentication, and this method is not in conflict with RFC 6749 Section 2.3, specifically 2.3.2 on alternative authentication methods.

That is to say, this is not something we feel needs correction due to some technical conflict or incompleteness within the standards. On the other hand, we would value simplicity taking into account overall ecosystem complexity and existing implementations.

[CDR-API-Stream]

The example referenced is for the Data Recipient calling the Data Holder and appears correct using the Self-Signed JWT method. It is different to the Private Key JWT method for Data Recipients calling Data Holders. For Maintenance Iteration 11, it is proposed that this issue be closed with no change.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call. It is proposed this change be closed with no change unless feedback is received during the maintenance iteration.