Archived 2023.08.11. Content moved to Guidance on revocation or withdrawal of consent
Under Client Authentication the Standards describe three scenarios under which participants in the CDR regime will authenticate clients seeking access to end points. This article looks only at Data Holders calling Data Recipients.
In the Standards, the audience or aud the data holder populates is specified to be the "base URI" of the endpoint being accessed. Depending on the endpoint being called, the base URI will be different.
For the CDR Arrangement Revocation Endpoint, the base URI is specified as the RecipientBaseUri that the ADR provides to the Data Holder in their Software Statement Assertion (SSA) during dynamic client registration. In other words, it is not the full path of the endpoint. ADRs validating the aud (audience) claim must verify that the value is the correct Recipient Base URI.
Where an explicit base URI is not provided in the SSA, then the URI of the endpoint itself should be used. A good example of this is the legacy ADR Token revocation endpoint which is specified as the RevocationUri in the SSA. Because the base URI is also the same as the fully qualified end point they would be the same.
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 …
token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
## Decoded Bearer token JWT
{
"alg":"PS256",
"typ":"JWT",
"kid":"67890"
}
{
"iss":"dataholderbrand-123",
"sub":"dataholderbrand-123",
"aud":"https://data.recipient.com.au",
"iat":1516239022,
"exp":1516239322,
"jti":"dba86502-7cf5-4719-9638-c5339a0ddb06"
}See Consumer Data Standards - Client Authentication
Comments
4 comments
This article appears tor redefine the internets definition of a base URI (which is the URL with no query or fragment parameter) into some "morphing" into RecipientBaseURI which contradicts the "end point being called" from the Standards.
The non-normative examples in the Standards are also misleading and the exact opposite of what this article states (see extract below). The sentence of "because the full path is also the BaseURI" is the direct opposite of what is stated in this article.
Yeah, I'm confused, sorry. This seems to differ from the current standards at https://consumerdatastandardsaustralia.github.io/standards/#data-holders-calling-data-recipients.
It is very dependent on your definition of base URI. In the example of https://data.recipient.com.au/revocation, I could calculate the base URI as https://data.recipient.com.au/, based on https://tools.ietf.org/html/rfc3986#section-5.1, which is different to both examples given above.
The comments here are reasonable. Initially the standards have used the term "holder path" for this reason. Over time the use of base URI in discussion has become more prevalent and this has crept into both the register and technical standards.
This article describes the correct intent of the standards and clarifies aud. We will raise a change request in standards maintenence to clarify the use of the term base URI and base path in the standards so there is no confusion between the standards and the usage of the same terms in the RFC.
Please refer to the following maintenance request:
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/373
Please sign in to leave a comment.