[Openid-specs-ab] aud & azp

Mike Jones Michael.Jones at microsoft.com
Tue Aug 11 03:36:58 UTC 2015


I posted a comment in reply.  You have the role assignments backwards in your example.  I double checked the meeting notes from the 6-May-13 in-person WG meeting at which we discussed what the definition of azp should be with Breno and confirmed this.

The last paragraph of my comment also identifies the text that’s actually causing the problem – calling both the requesting client and the issued-to client “the Client” – causing the resulting ambiguity.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Monday, August 10, 2015 6:46 PM
To: Mike Jones
Cc: Justin Richer; Brian Campbell; openid-specs-ab at lists.openid.net Ab
Subject: Re: [Openid-specs-ab] aud & azp

Just posted a comment on the ticket. Please have a look.

2015-08-11 10:03 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>:
Yes, the spec requires that the requestor’s Client ID be returned as an “aud”.  If present, the “azp” claim can either contain this Client ID or another value identifying another party that the requester will also pass the token to.

In retrospect, we probably should have just required that this party be an additional “aud” value, but that’s water under the bridge now.

                                                            -- Mike

From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Justin Richer
Sent: Monday, August 10, 2015 5:25 PM
To: Brian Campbell
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net> Ab

Subject: Re: [Openid-specs-ab] aud & azp

I agree with Brian’s reading on this, and our client software actually enforces this when it’s checking things.

 — Justin

On Aug 10, 2015, at 6:10 PM, Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>> wrote:

It's not totally clear what the spec allows or prescribes, which is where the issue for errata<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%2f973%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1X6TMVZkgP6mCuDtNEy4RboKjyzk1OaMTBXQU4OkY00%3d> originates. And there seems, from the last call anyway<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fpipermail%2fopenid-specs-ab%2fWeek-of-Mon-20150803%2f005637.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QtgrqR6j0IUHMsE1ObrVUMBMmmiptvGa0cwnVrYkEks%3d>, to be a lack of agreement about what the intent actually was.

It's my belief that the client id of the RP/client that made the authentication request should always be represented in the aud of the returned ID Token.


On Mon, Aug 10, 2015 at 12:51 PM, Preibisch, Sascha H <Sascha.Preibisch at ca.com<mailto:Sascha.Preibisch at ca.com>> wrote:
Just to make sure that I got it right:

  *   it is possible that a JWT does not include the client_id (neither in “aud" nor in “azp") of the client who has sent the request, correct?
If I am wrong I may misunderstood your text Brian and would be happy for some clarification.

Thanks, Sascha

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>>
Date: Thursday, August 6, 2015 at 5:47 AM
To: Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
Cc: "<openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>" <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: Re: [Openid-specs-ab] aud & azp

Sure, https://bitbucket.org/openid/connect/issues/973/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%2f973%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1X6TMVZkgP6mCuDtNEy4RboKjyzk1OaMTBXQU4OkY00%3d>

On Wed, Aug 5, 2015 at 5:13 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Thanks for bringing this up, Brian.  Could you file this as an issue against the “errata” deliverable and the core spec at https://bitbucket.org/openid/connect/issues?status=new&status=open<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbitbucket.org%2fopenid%2fconnect%2fissues%3fstatus%3dnew%26status%3dopen&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6da24809a22c47ac916008d2a1e34e20%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CGNQaZLJDEyJwnLJ3nf6XHz0ceOqet%2bdURZK%2b6a3gfU%3d>?  We should talk about this on tomorrow morning’s working group call.  After you do, I’ll add the following as a comment on the issue…

I think the problematic language is “the Client” in the statement below:

If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.

The problem is that the azp Client can be different than the requesting client.  It’s the azp Client that needs to do this validation step, not the requesting client.  Do people agree with this?

                                                                -- Mike

From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Brian Campbell
Sent: Wednesday, August 05, 2015 10:11 AM
To: <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: [Openid-specs-ab] aud & azp

I find the text around azp and aud to be rather unclear and I think there's a potential item for errata in it somewhere.
From the definition of "aud" in JWT<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d> and its use in Connect's ID Token<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d> (relevant spec text is copied below), it seems that that the client id of the client/RP that made the authentication request has to be one of the values, or the only value, of the "aud" claim in the ID Token. That's logical and consistent and provides reliable and interoperable guidance to implementers about producing and consuming the ID Token. I think that the client id of the RP/client that made the authentication request should always be represented in the aud of the returned ID Token.
The text around "azp" in the ID Token section<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d> and the ID Token Validation section<https://na01.safelinks.protection.outlook.com/?url=+http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LrFoSF%2bqjC75ilCneT3yFXJ30Nu8nu%2fbsj5LiEKJkus%3d> seems to maybe suggest something different, however. Like perhaps that the client id of the RP/client that made the authentication request could, in some totally unspecified circumstance, be the value of the azp claim and that the aud would not identify that client as an intended recipient. Am I misinterpreting things? I hope so because that seems like it'd be fragile from an interop perspective and is certainly more cumbersome for general JWT libraries to support.


from http://tools.ietf.org/html/rfc7519#section-4.1.3<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d>

 4.1.3.  "aud" (Audience) Claim

   The "aud" (audience) claim identifies the recipients that the JWT is
   intended for.  Each principal intended to process the JWT MUST
   identify itself with a value in the audience claim.  If the principal
   processing the claim does not identify itself with a value in the
   "aud" claim when this claim is present, then the JWT MUST be
   rejected.  In the general case, the "aud" value is an array of case-
   sensitive strings, each containing a StringOrURI value.  In the
   special case when the JWT has one audience, the "aud" value MAY be a
   single case-sensitive string containing a StringOrURI value.  The
   interpretation of audience values is generally application specific.
   Use of this claim is OPTIONAL.


from http://openid.net/specs/openid-connect-core-1_0.html#IDToken<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
  ...
  aud
REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.
  ...
  azp
OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The azp value is a case sensitive string containing a StringOrURI value.
  ...

from http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ko0MzMkFxNMQmWPYs%2fPYGgMvPE2m%2bhuj4vIUBIwyz1M%3d>

  Clients MUST validate the ID Token in the Token Response in the following manner:
...
4. If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.
...
5. If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.
...
8 If the JWT alg Header Parameter uses a MAC based algorithm such as HS256, HS384, or HS512, the octets of the UTF-8 representation of the client_secret corresponding to the client_id contained in the aud (audience) Claim are used as the key to validate the signature. For MAC based algorithms, the behavior is unspecified if the aud is multi-valued or if an azp value is present that is different than the aud value.
The current time MUST be before the time represented by the exp Claim.



_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9b40d8ecdd2041e58bbf08d2a1ee9745%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MEEEAeTBRgawHv6Qnf1%2fxTjx5ZC%2flQx6si4zTE480Z0%3d>


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9b40d8ecdd2041e58bbf08d2a1ee9745%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MEEEAeTBRgawHv6Qnf1%2fxTjx5ZC%2flQx6si4zTE480Z0%3d>



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9b40d8ecdd2041e58bbf08d2a1ee9745%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OxFaDXVU3pHjp7So%2fgw1zV8D7znmNB72fjyC6NtmekM%3d>
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150811/c74475c3/attachment-0001.html>


More information about the Openid-specs-ab mailing list