- edited description
Mesages - 2.1.2.1 "azp" definition too restrictive
Currently:
azp
OPTIONAL. Authorized Party. This member identifies an OAuth 2.0
client authorized to use this ID Token as an OAuth access token,
if different than the Client that requested the ID Token. It MUST contain
the client_id of the authorized party.
Proposal:
azp
OPTIONAL. Authorized Party. This member identifies an OAuth 2.0
client authorized to use this ID Token as an OAuth access token.
It MUST contain the identifier that the protected resource recognizes.
Rationale:
Current text needlessly constrains what azp could be, while that constraint being not necessarily useful. For example, the current definition removes the possibility of having ephemeral identifier (such as a dynamically generated public key) of the client, which is not a client_id in the OAuth sense but still useful as long as the protected resource can recognize it and possibly perform the key possession check.
Comments (18)
-
reporter -
reporter - changed title to Mesages - 2.1.2.1 "azp" definition too restrictive
-
- changed milestone to Implementor's Draft
-
assigned issue to
The "if" language should be changed to say that "azp" is OPTIONAL when the authorized party is the Client that requested the ID Token.
The working group is against the second change that would not require "azp" to be the client_id.
-
reporter - changed milestone to Implementer's Draft
-
- changed status to resolved
Fixed
#712- "azp" definition clarification→ <<cset 81ed6cf7f840>>
-
Account Deleted (Reply via bren...@gmail.com):
Please drop "as an OAuth access token". What about "as an assertion of the identity of the subject suitable for authenticating the subject to the specified audience."
-
reporter - changed status to open
Breno's comment is not yet resolved.
-
reporter azp OPTIONAL. Authorized Presenter. This member identifies an OAuth 2.0 Client authorized to use this ID Token. It MUST contain the client_id of the Authorized Presenter.
-
We agreed on the call to delete the phrase "as an OAuth access token". We don't think it's necessary to add the second phrase, which is confusing - at least as written.
-
reporter -
assigned issue to
It is now John's turn to come up with the specific amended text as per Apr. 4 call.
-
assigned issue to
-
azp OPTIONAL. This field identifies the entity presenting the ID Token to the resource endpoint and SHOULD contain a value verifiable by the resource endpoint.
-
Possible text for the 'aud' field in the Messages spec 2.1.2.1
aud REQUIRED. Audience that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Client and MAY additionally contain other audience identifiers as necessary.
-
Messages - Section 5.2 - ID_TOKEN Validation
Step 3. If the token contains an 'azp' value (may be a list) the client SHOULD validate the value(s) of the azp however the mechanism to validate such values is outside the scope of this document.
-
Need to make 'azp' multi-valued. Same model as 'aud' field from JWT.
In the general case, the "azp" value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "azp" value MAY be a single case sensitive string containing a StringOrURI value.
-
- changed status to resolved
Fixed
#712- Clarified the "azp" description and made "azp" multi-valued, like "aud". Fixed#830- Clarified that "aud" of an ID Token must contain the Client ID of the Relying Party.→ <<cset fd362360436a>>
-
reporter - changed status to open
Temporarily reopening as there is a new ticket
#973which is essentailly a dup of it. Also, since some of the things which happened after the fact was not recorded, I am now recording them after reopening it. -
reporter Apparently, in the May 6, 2013 F2F, there was a discussion and decision around it. The meeting note is available as: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html
The relevant part of the note is as follows:
Expected behavior of time fields when using Refresh Tokens We determined that the language in Messages 2.2.3 (Access Token Response) needs a few enhancements We need to include "aud" in the list of elements that must be the same We will further clarify that "azp" must be the same We will format the requirements as a bulleted list, for better readability Review audience/azp semantics We will clarify that when an ID Token is used as a hint, that the party receiving the hint need not be an audience of the token Relying parties expressed a need to be able to know who the ID Token is issued to We decided that we will use the "azp" field for this "azp" will be single-valued While ideally this would be named something closer to "issued to", we will leave the name "azp" so as not to break existing deployments Breno pointed out that originally we had an issued_to field but that it was removed. This brings us full circle.
Attached images are: * http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg * http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg
-
- changed status to resolved
The “azp” description was updated after the in-person OpenID Connect working group meeting at Google on 6-May-13, in which we agreed that “azp” would be used to represent the issued-to information, and that the claim would be named “Authorized Party”. See the meeting notes at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html, including attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg, which documents that we decided to represent issued-to information with “azp” and attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg, which documents that the “azp” claim is to represent an “Authorized Party”. We also decided to make “azp” single-valued there, where it had previously been multi-valued.
Breno de Medeiros and Naveen Agarwal of Google were at the meeting, and in fact, were behind many of these changes, which is significant, since they were the inventors of this functionality. They concurred with and participated developing these resolutions previously open issues about the meanings of “aud” and “azp”. Afterwards, the meeting notes were sent to the working group mailing list for review there and no objections were raised.
Furthermore, all of this text went through both the 45 day Implementer’s Draft 2 public review period announced at http://openid.net/2013/06/07/review-of-proposed-openid-connect-implementers-drafts/ and the 60 day Final Specification public review period announced at http://openid.net/2013/12/20/review-of-proposed-final-openid-connect-specifications-and-implementers-drafts/, and no objections were raised during those reviews either. People seemed happy with the resolution arrived at during the working group meeting.
So in conclusion, it would probably be less confusing to all concerned if people were to stop referring to “azp” as “authorized presenter” or ascribing those semantics to it (whatever those may be). Sometime before Implementer’s Draft 2 of OpenID Connect that terminology was used, but the working group changed that and the meaning of “azp” by consensus in May 2013 and it’s been that way ever since. Trying to overload “azp” with a different meaning than what’s in the standard seems counterproductive.
This is all documented now both in the working group mailing list archives and the issue tracker, so I'm re-closing the bug.
- Log in to comment