Align how audience is set for 'Data Recipients calling Data Holders’

[anzbankau]

Following on from previous discussions in both the ACCC Registry and standards github issues: https://github.com/cdr-register/register/issues/58 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/53

We are proposing that the standards are changed for the section ‘Data Recipients calling Data Holders’ of: https://consumerdatastandardsaustralia.github.io/standards/#client-authentication So that the audience in this scenario is set in the same way as for DCR and the Request object – i.e. set to the issuer that is returned from the Data Holder’s OIDC well-known end point.

This is so that for these different scenarios the audience is set in a consistent way, which is required as in all cases the authorisation server is the same.

As part of this change we will also be updating our issuer returned in OIDC well-known so that it is set to the token end point of our authorisation server. This is to align closer to the OIDC specifications at: https://openid.net/specs/openid-connect-core-1_0-15.html#ClientAuthentication aud REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

ANZ is looking to make this change urgently as part of the next iteration of the standards and for this change to be effective immediately. ANZ is looking for community support on this proposal in order to align with OIDC, as deviations from OIDC will increase the complexities of implementation and ability to use vendor based products. If the current standard is not changed, customisations will be required which impacts the delivery cost and maintainability, not just for ANZ, but for the wider community.

[mark-nienaber]

The issue register here : https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/53 resolves the initial confusion of the aud value for Data Recipients calling Data Holders, and it was determined the aud value must be set to the issuer that is returned from the Data Holder’s OIDC well-known end point. This would mean the current CDR standard defers to the OIDC standard on this matter.

It is requested that the expected value for aud be clarified or confirmed as being the "issuer that is returned from the Data Holder’s OIDC well-known end point" and that the CDR standard does not intend to overule the OIDC standard.

It is also recommended that existing standard be modified to be more clear on this matter and that the phrase "aud: The URL of the end point being invoked." be changed as per the request by ANZ above.

[CDR-API-Stream]

The change has been labelled as urgent by request

[perlboy]

As part of this change we will also be updating our issuer returned in OIDC well-known so that it is set to the token end point of our authorisation server.

1. The token endpoint is not the issuer for discovery purposes.
2. The aud for POST /token is intended to be the token endpoint

Setting the issuer in the discovery document to the token endpoint breaks webfinger support and OIDC Discovery compliance because a discovery document request MUST be base pathed off the issuer. Setting the issuer to [host]/token would result in a requirement for the original request to be [host]/token/.well-known/... or it should be rejected. A derivation of this problem was discussed at length within the FAPI WG some time ago and the prevailing statement is that, for injection attack mitigation, the document response and request path should be rigidly enforced (despite some OBUK banks not complying).

From the OpenID Discovery spec:

issuer REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

Specifically with regards to this statement:

The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

SHOULD being the operative word. In fact an audience that matches the issuer is also valid by proxy of the following statement from RFC7523:

3. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The token endpoint URL of the authorization server MAY be used as a value for an "aud" element to identify the authorization server as an intended audience of the JWT. The authorization server MUST reject any JWT that does not contain its own identity as the intended audience. In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986]. As noted in Section 5, the precise strings to be used as the audience for a given authorization server must be configured out of band by the authorization server and the issuer of the JWT.

It would appear the supplied example of "aud": "https://www.holder.com.au/token", is accurate and the description of aud: The URL of the end point being invoked while ambiguous is accurate too (albeit, perhaps explicitly calling it "token endpoint" would be helpful).

Suffice to say, advertising an issuer set to the token endpoint which appears to be suggested by @anzbankau would be incorrect and break OIDC Discovery compliance.

[perlboy]

Further, the reference to the discussion with respect to the cdr-register is an incorrect connection for a different use case.

The cdr-register issue highlighted refers to a registration request whereby the token endpoint is not in scope. The audience is, accurately, the issuer itself because this is a negotiation occurring to decide how to talk to a token endpoint (not intended to actually be consumed by the token endpoint).

Conversely, in the case of the Data Recipient calling the Data Holder with a /POST token the audience should be the token endpoint but strictly speaking as long as the OP receives a value it considers valid (typically token or issuer URIs) it is a valid request.

[perlboy]

Further again, the comment made @mark-nienaber also references a different use case regarding Request Objects.

aud is not intended to be the same across these requests. aud is the audience of the request and the audience of the request is contextually defined based on the type of request. Aligning these across request types is invalid and will definitely break standards based implementations.

[jogu]

I agree with @perlboy - the standards currently appear to correctly align with the upstream standards, and making the changes suggested in this issue would harm interoperability significantly.

[anzbankau]

Thanks for the inputs from the community so far. We would like to clarify that our key ask is that the audience should be consistent between these different use cases, including the end points: Revoke, Introspection and Token.

Audience is the authorisation server that authenticates the client, and is not the resource server end point.

Audience shouldn’t be the resource being accessed. For example, if the Register is trying to access /metrics, the audience wouldn't be the /metrics end points.

As per the comment from @perlboy , the OIDC standards only state that the token end point audience 'SHOULD' be set to the URL of the token end point. Thus our proposed approach shouldn't break OIDC standards.

[perlboy]

Thanks for the inputs from the community so far. We would like to clarify that our key ask is that the audience should be consistent between these different use cases, including the end points: Revoke, Introspection and Token.

So this is slightly different than what the original statement implied:

So that the audience in this scenario is set in the same way as for DCR and the Request object – i.e. set to the issuer that is returned from the Data Holder’s OIDC well-known end point.

Fundamentally aud is essentially consistently applied in all specifications as representing the intended audience.

Working through the three: 1) Token: The audience is the specific token endpoint because ONLY the token endpoint can issue the token required. IF this was a PAR request the audience would be /par for this exact same reasons. 2) Revocation: This endpoint is not technically part of the OIDC standard BUT according to the Standards is intended to be an RFC7009 request. This specification specifies no audience at all because the authorative component is the presented token. 3) Introspection: As per RFC7662 the introspection endpoint optionally responds with an aud claim. If it is provided this response is intended to be used by the requestor to validate whether the presented and introspected token is intended to be accessing the resource server endpoint. While not required to be provided in the base spec it is a useful response to allow border control implementation with scope enforcement delegated to an internal service. Now, with this said, the CDR Standards explicitly state that only active and exp fields are to be supplied.

On the above basis, your request for all 3 to be aligned is moot because only one of them the POST /token endpoint includes it.

Audience is the authorisation server that authenticates the client, and is not the resource server end point.

This is an incorrect statement. In RFC7662, if aud was available it would be up to the OP/RP to decide how to process it. The spec itself refers to RFC7519 which defines it as anything they agree on as long as it isn't null. As per the example supplied in RFC7662 the aud response, if used, is typically a resource server (or list of resource server) URIs.

Repasting what I previously said:

aud is not intended to be the same across these requests. aud is the audience of the request and the audience of the request is contextually defined based on the type of request. Aligning these across request types is invalid and will definitely break standards based implementations.

Please reread the relevent specifications and stop treating aud like some static and globally defined attribute. It isn't and it was never intended to be.

Audience shouldn’t be the resource being accessed. For example, if the Register is trying to access /metrics, the audience wouldn't be the /metrics end points.

Once again, this is incorrect.

If the Register was accessing /metrics it would be issued a token. That token might be a JWT which would have it's client id as the audience or it might be opaque. Either way, when it is presented to the resource server for GET /metrics the resource server should/would seek to introspect it at the OAuth2 server. IF this internal comms flow DECIDED to support aud claim then the /metrics endpoint may very well be in the list of resources supplied within aud.

Once again, there is a convoluting in use cases occurring here to try and goal seek a situation where aud is always going to be some sort of static variable.

As per the comment from @perlboy , the OIDC standards only state that the token end point audience 'SHOULD' be set to the URL of the token end point. Thus our proposed approach shouldn't break OIDC standards.

If your intention is to enforce aud to be the issuer which, for the purposes of simplification is the root uri from which GET /token is called, then a presentation of an aud including /token would still be valid because the issuer is a base uri matching attribute. That is to say both http://issuer/ and http://issuer/token are valid.

If your intention is to enforce aud to be the issuer and reject requests that are not an explicit match this would break standards.

Either way, essentially ALL current client libraries perform POST /token with an aud set to the token endpoint that has been discovered from OIDC.

Somewhat related is that the FAPI WG members discussed the appropriate value for aud within the CIBA specification and came to the conclusion that In order to facilitate interoperability the OP MUST accept its Issuer Identifier, Token Endpoint URL, or Backchannel Authentication Endpoint URL as values that identify it as an intended audience. Likewise the PAR spec also has an open issue to tighten this restriction up with consideration of alignment with the CIBA definition.

[NationalAustraliaBank]

NAB believe the standards in their current form reflect the underlying OIDC standards regarding the use of aud. Therefore we don’t believe any changes are required due to this issue.

[jogu]

As per the comment from @perlboy , the OIDC standards only state that the token end point audience 'SHOULD' be set to the URL of the token end point. Thus our proposed approach shouldn't break OIDC standards.

Whilst it would technically only be contravening a recommendation in the spec, it would be incredibly bad for interoperability with/support by pretty much all existing OIDC clients and servers. That is a rather large downside.

[anzbankau]

Thanks for the further inputs from various participants. Given the lack of support thus far to changing the CDR standards we are happy to withdraw the changes we have proposed. It is understandable at this point of implementation that change is not desired.

We have provided some responses below to provide clarity on our interpretation of various standards that have been mentioned.

The audience claim is the item in question here, and is discussed in context of client authentication mechanism using private_key_jwt.

The CDR specification state: _“Data Holders MUST support the authentication of Data Recipients using the private_keyjwt Client Authentication method specified at section 9 of [OIDC].”

Section 9 as per the OIDC references private_key_jwt and states the following: aud REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

In response to comments from @perlboy on the aud for various end points:

1. Token end point: “The audience is the specific token endpoint because ONLY the token endpoint can issue the token required. IF this was a PAR request the audience would be /par for this exact same reasons.” This is not our interpretation. /PAR is only a valid audience if it in any way represents the authorisation server. Please refer to “MUST” from OIDC on intended audience for token to be Authorisation server.

2. Revocation end point: “This specification specifies no audience at all because the authorative component is the presented token.” Once again, this is not our interpretation. The authoritative source is not just the token component present for revocation. Reference from RFC7009

The authorization server first validates the client credentials (in case of a confidential client) and then verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is refused and the client is informed of the error by the authorization server as described below.

Although RFC7009 quoted is not OIDC, it does explicitly callout client authentication must still be performed before revocation can happen. Security consideration in RFC further provides reason for it to stop malicious attack. Supported mechanism per CDR for client authentication is again private_key_jwt per OIDC Section 9. In which case audience needs to be value which tells authorisation server as its intended audience.

3. Introspection end point – Reference from RFC7662: To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750].

Supported for client authentication as per CDR from DH to ADR is again private_key_jwt as per the OIDC Section 9.

Whilst standard reference quoted for RFC7519 on the use of aud within JWT is correct, it’s not specific to apply in case of client authentication using private_key_jwt of OIDC.

Setting audience to the endpoint invoked is only strictly true during OIDC client authentication if the end point in some way reflects the authorisation server as intended audience.

[perlboy]

Honestly @anzbankau, this is looking more and more confused so I'm not even sure I should be responding but nonetheless.

The audience claim is the item in question here, and is discussed in context of client authentication mechanism using private_keyjwt. The CDR specification state: “Data Holders MUST support the authentication of Data Recipients using the private_keyjwt Client Authentication method specified at section 9 of [OIDC].” Section 9 as per the OIDC references private_key_jwt and states the following: aud REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

This omits the explicit statement prior to this claim list (which is a profile of what claims must be supported for private_key_jwt) of: The Client authenticates in accordance with JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.JWT] and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.Assertions].

In response to comments from @perlboy on the aud for various end points:

1. Token end point: “The audience is the specific token endpoint because ONLY the token endpoint can issue the token required. IF this was a PAR request the audience would be /par for this exact same reasons.” This is not our interpretation. /PAR is only a valid audience if it in any way represents the authorisation server. Please refer to “MUST” from OIDC on intended audience for token to be Authorisation server.

You've missed my point. The aud of POST /token (or whatever discovered token endpoint is in play) is recommended to be [issuer]/token/"[token_endpoint] from discovery doc" because only this endpoint can issue tokens. The PAR example was given because only the POST /par endpoint (or whatever the discovered endpoint is) can issue object references accepted by the auth server in a subsequent call to authorise. Neither of these provides any justification for fiddling with issuer and, as I stated before, an OP should accept POST /token requests with an aud of both it's token endpoint OR it's issuer.

This was explained in my previously linked thread where the original author of the spec, Brian Campbell, highlighted that the reason this aud value ended up being set to this is because, at the time, issuer didn't even exist. This historical background led to the spec being watered down to SHOULD and subsequent specs being broad on verification.

2. Revocation end point: “This specification specifies no audience at all because the authorative component is the presented token.” Once again, this is not our interpretation. The authoritative source is not just the token component present for revocation. Reference from RFC7009 The authorization server first validates the client credentials (in case of a confidential client) and then verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is refused and the client is informed of the error by the authorization server as described below.

Once again, you've missed my point. There is no aud being verified. The token is validated as belonging to the client in question (irrespective of what client authentication is in use) and that it is valid so it can be revoked.

Does the token contain an aud value? If it's a JWT, Sure. If it's Opaque, No.

Even assuming exclusively JWT's, modifying the aud is impossible without breaking the cryptographic signature (or deciding to be entirely silly and disabling signing) of that JWT so, as I said before, it's moot because the aud in play for the token will be set to the Recipients client_id anyway.

Although RFC7009 quoted is not OIDC, it does explicitly callout client authentication must still be performed before revocation can happen. Security consideration in RFC further provides reason for it to stop malicious attack. Supported mechanism per CDR for client authentication is again private_key_jwt per OIDC Section 9. In which case audience needs to be value which tells authorisation server as its intended audience.

You've gone off the deep end of client authentication when that isn't the area under discussion. I never implied that the token shouldn't be appropriately verified, instead I said that the aud is of no relevance here because [complete with misspelling] the "authorative component is the presented token".

1. Introspection end point – Reference from RFC7662: To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. Supported for client authentication as per CDR from DH to ADR is again private_key_jwt as per the OIDC Section 9. Whilst standard reference quoted for RFC7519 on the use of aud within JWT is correct, it’s not specific to apply in case of client authentication using private_key_jwt of OIDC.

Once again, you've gone off the deep end and decided to focus on client authentication which was never in scope of this conversation. For the record, I didn't in-scope revocation or introspection here, you did by asking for them to be "consistent between these different use cases, including the end points: Revoke, Introspection and Token." which I classify as an attempt to deliberately tamper with widely accepted understanding of aud values combined with confusion about what aud values are set in what components.

Setting audience to the endpoint invoked is only strictly true during OIDC client authentication if the end point in some way reflects the authorisation server as intended audience.

You need to go read the spec again. aud has never been in the POST /introspect call. MAYBE the token supplied has an aud in it (IF it's a JWT) but this is unrelated to the introspection call itself and client authentication is wrapped up during the token verification process overlaying all these calls.

In summary, POST /token is historically (until PAR came along) the only location within which aud is used as part of path (not client, not token, not anything else) validation. The history of this is because there was no such thing as issuer when the spec was written. The issuer was introduced and this resulted in the aud recommendation being a SHOULD. The spec text is very broad about what is an acceptable value (almost to the point of being a wildcard) and, in an effort to tighten things up in subsequent specs (ie. CIBA) the authors, one of whom is both the original author of the spec being discussed here AND the CIBA spec, decided to be more explicit as I've previously quoted.

Key takeaways:

1. issuer should be the base uri from which OIDC Discovery (and potentially WebFinger) requests are made from
2. token_endpoint from the discovery document should point to the uri for what is described as POST /token in specs
3. The aud for a POST /token call SHOULD be set to [token endpoint] and the OP is expected to accept it
4. If the aud for a POST /token call is set to the [issuer] the OP is expected to accept it

Finally, not complying with (3) and (4) was already historically debated by OBIE in 2018 and one particularly stubborn (and for now nameless) vendor was formally sanctioned by OIDF. Please don't turn this into groundhog day.

[commbankoss]

Commonwealth Bank also believe the standards in their current form are aligned with the underlying OIDC standards regarding the use of aud. Therefore we don’t believe any changes are required due to this issue.

[perlboy]

I've said plenty in this thread but I'll just reiterate the one potential improvement I see regarding the text for aud which says The URL of the end point being invoked

Suggest this is improved to The Token Endpoint URL or a direct reference to the SHOULD statement in underlying spec. Given the discussion my personal preference would be for the DSB to explicitly declare this must be the token endpoint.

[mark-nienaber]

With respect to the following comment made by @perlboy , I agree that the changing of the text URL of the end point being invoked to be more specific would remove unnecessary confusion.

Suggest this is improved to The Token Endpoint URL or a direct reference to the SHOULD statement in underlying spec. Given the discussion my personal preference would be for the DSB to explicitly declare this must be the token endpoint.

[CDR-API-Stream]

As per the Maintenance Iteration call on the 14th of May, the proposed change that participants have provided above is accepted.

Proposed change: Update:

The URL of the end point being invoked.

To:

The Token Endpoint URL.

[mark-nienaber]

As per the Maintenance Iteration call on the 14th of May, the proposed change that participants have provided above is accepted.

Proposed change: Update:

The URL of the end point being invoked.

To:

The Token Endpoint URL.

ForgeRock supports this change which is in line with underlying standards and feels the change will alleviate confusion on this topic.

[pcurtisrab]

Given #325 is raised it seems necessary to clarify the rationale for adopting this proposal.

While the discussion of this issue has touched on various specifications and endpoints, the thread of logic has not been clear. Disambiguation is needed.

It appears to us that the statement in the underlying standards in the original proposal:

The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

has been taken out of context. That statement in the OIDC spec is from Section 9 - Client Authentication which is specifically about the token endpoint only. However, Client Authentication in the CDS has evolved to cover a wider scope, which includes in addition to the token endpoint; revocation, introspection and arrangement management.

This is why that specific statement cannot be imported verbatim into the CDS without generalising it. Generalising it requires considering the reasoning for the specific recommendation in OIDC, and how that applies in general. In our view it is clear that this reasoning comes from a general need to bind the JWT to the containing request. The salient reason for this is preventing the tokens for one audience being intercepted or generated and applied to another audience for nefarious purposes. One extreme example of that would be to use client assertions generated for one Data Holder to access data from another Data Holder. This is solved by using the audience to bind that request to a specific audience (in this example, audiences varying between data holders). The audience claim is the only mechanism within the JWT for preventing this kind of attack.

However, in our context where Client Authentication also includes revocation, introspection and arrangement management, a more subtle variation exists where the audience varies not just between data holders but also between endpoints for a single data holder. For example, if an attacker is able to intercept or generate assertions for one low sensitivity audience (e.g. introspection endpoint or recovation, or arrangement management endpoint), they may be able to use that assertion to request an access token at the token endpoint (a different higher sensitivity audience). In this light, this proposal to align the audience across endpoints introduces additional data security risk which may be unwarranted.

Coming back to ANZ's initial proposal, our view is that data holders should be free to verify the audience with the issuer if they like (or token URL for that matter). However, Data Recipients also seek a simple implementation where they can use one method of discovery across data recipients. We think that the original statements struck a good balance between security, uniform discoverability and standards alignment in attempting to generalise that as "the base URI for the end point being accessed", however, the "MUST be" in front of that wrongly dictates that the DH cannot accept another value compliant with the underlying standards.

We think that a pragmatic solution is to change the wording from:

aud - REQUIRED. Audience. The aud (audience) Claim. Value that identifies the intended audience. The Data Holder or Data Recipient MUST verify that it is an intended audience for the token. Contents MUST be the base URI for the end point being accessed.

to

aud - REQUIRED. Audience. The aud (audience) Claim. Value that identifies the intended audience. The Data Holder or Data Recipient MUST verify that it is an intended audience for the token. The base URI (protocol, host and path) for the end point being accessed must be accepted as a valid value for the aud claim:

The benefits of this approach are:

• It is already implemented
• There is nothing stopping data holders achieving compliance with upstream standards

The token endpoint as proposed would work, and I am told that this is already a pattern like this in the industry, but there does not seem to be a reason to chose this for ALL auth-related endpoints from the standards alone.

In the end, we don't mind too much which balance is struck, only that a reliable method for valid audience prediction for a DR implementation remains, and that the rationale for the decision is clearly set out for future reference.

[jogu]

For example, if an attacker is able to intercept or generate assertions for one low sensitivity audience (e.g. introspection endpoint or recovation, or arrangement management endpoint), they may be able to use that assertion to request an access token at the token endpoint (a different higher sensitivity audience).

I'm not sure this is an important scenario. If you think it is important I'd suggest you raise it on the IETF OAuth2 working group mailing list, as the above text I quote from the PAR endpoint could still be changed as the PAR spec hasn't gone to RFC status yet. If it is an issue, it should be fixed at the IETF level, and then the various open source libraries that various data recipients do/will rely on will also be fixed, and vendor products that data holders use will be updated, the conformance suites for those specs will check that behaviour, and so on.

There is nothing stopping data holders achieving compliance with upstream standards

By definition, requiring or allowing holders to refuse an aud value that the upstream standards (PAR/CIBA) require them to accept puts them (or allows them to be) out of compliance with the upstream standard. I don't see the need for flexibility here. It's either an issue and should be fixed in the upstream specs mentioned, or it's not an issue and CDR should not make changes that unnecessarily break interoperability with the upstream specs.

[pcurtisrab]

@jogu, could you be specific about which statement in an upstream standard would be violated by the wording I have proposed? We should look at my proposed statement in closer detail:

The base URI (protocol, host and path) for the end point being accessed MUST be accepted as a valid value for the aud claim.

For clarity, I do not mean this to contradict that the Data Holder MAY accept another value that it deems valid or as required by upstream specs.

Indeed, PAR states, and this would be allowed by my proposed wording:

In order to facilitate interoperability the AS MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

Also, CIBA (for better or worse), is not in scope within the CDS as far as I can tell.

I could have easily overlooked something but the intention behind that statement is to be compatible with upstream standards while representing the current state of implementation. Perhaps someone else could make a better go of it.

[jogu]

The statements I was referring to are the two you've quoted. As I understand it, your wording allows CDR DH to be compliant with the underlying standards, but doesn't require them to be compliant.

I'm not clear why CDR would want to appear to make adherence to the upstream standard optional.

[jogu]

For clarity, my suggestion is that CDR moves straight to aligning the standards text with the underlying standards. If necessary with an 'alignment period' to allow people that are already live time to update their systems to accept the extra values.

[pcurtisrab]

Hi @jogu, I must admit that I am getting a bit lost here.

Requiring DHs to be compliant, AND providing predictability to DR's, is the exact goal and intended result of my suggested wording. It's not my intention at all to make adherence to upstream standards optional. I had hoped that my comments would make that clear.

After further reviewing this comment of yours on #325, I think I am pretty much aligned with you on what the wording should be.

I think the source of my confusion is that you are talking about CIBA as if it is an upstream standard. If it was, I would agree with your comments completely. (FWIW, I also think you rightly question my comments on aud varying within a data holder).

[pcurtisrab]

@CDR-API-Stream , would it be worth clarifying precisely:

1. Is CIBA considered an upstream standard?
2. What exactly are the alternative wordings that have been put forward?

[jogu]

As I understand things, your suggested wording is:

aud - REQUIRED. Audience. The aud (audience) Claim. Value that identifies the intended audience. The Data Holder or Data Recipient MUST verify that it is an intended audience for the token. The base URI (protocol, host and path) for the end point being accessed must be accepted as a valid value for the aud claim.

However, for at least the PAR endpoint (PAR is in scope for CDR), DH are also required to accept the issuer and the token endpoint (as well as the PAR endpoint) in the aud for client assertion. So I think text that states the DH must accept the endpoint being called as the aud is at best misleading, as DH are also required to accept other aud values as per the PAR standard. In my opinion, the sensible think to do (and intent, as clarified by at least one of the authors of the client authentication assertion RFC) is that the text in the PAR standard can be applied to all endpoints.

(I think I introduced confusion by explaining that the CIBA spec is where this clarification of the intent was originally stated, and the text used in the CIBA spec was later adopted in the PAR spec.)

[pcurtisrab]

@jogu, you quote my suggested wording correctly, but interpret it differently than I would expect, so maybe it is not a good suggestion.

In my opinion, the sensible think to do (and intent, as clarified by at least one of the authors of the client authentication assertion RFC) is that the text in the PAR standard can be applied to all endpoints.

I agree.

[CDR-API-Stream]

A change to the data standards was originally approved by the Data Standards Chair for inclusion in v1.4.0. Following further consultation, a revised and improved change was approved by the Data Standards Chair for inclusion in v1.6.0.

This issue will be closed accordingly.