[Openid-specs-ab] Your help needed clarifying Google's "azp" claim usage

[Mike Jones]

Thanks guys.  A few follow-up questions…

Which Client ID is used in the Authentication Request to the OP – the Client ID of the Android App or the Client ID of the app’s home server?  Also, what information are you adding to the Authentication Request to tell the OP to issue a token with the audience being the app’s home server and the “azp” being the Android application?

                                                            -- Mike

From: William Denniss [mailto:wdenniss at google.com]
Sent: Wednesday, August 19, 2015 11:39 PM
To: Adam Dawes
Cc: Mike Jones; Breno de Medeiros; Naveen Agarwal; openid-specs-ab at lists.openid.net; John Bradley
Subject: Re: [Openid-specs-ab] Your help needed clarifying Google's "azp" claim usage

So our interpretation is that 'azp' is the party who the token was issued to, 'aud' is the party who the token was intended for. The expectation being that the 'azp' client is presenting the token to their server (the 'aud').  For our Android API, both client-ids must be registered under the same parent project (i.e. you can't request an id token for an arbitrary client id that you don't also own, and isn't a member of the same project).

Of the two names, I think I prefer "Authorized Presenter" over "Authorized Party", as azp refers to the client authorized to present the token to the server.

The server could always choose to accept an ID Token issued with an 'aud' of its client app directly, this just makes the semantic a little more explicit I guess.

It is curious that we have documented the claim semantic, without actually having a standards-compliant way to request such a token. I wonder if that's something we should address. It could be relevant for the NAPPS effort.

On Wed, Aug 19, 2015 at 10:57 PM, Adam Dawes <adawes at google.com<mailto:adawes at google.com>> wrote:
From one of our engineers:

AFAIU, the only case where "azp" is different from "aud" is Android cross-client ID token.
In that case, the azp is the ID token requestor, which is the Android app, and the audience is the app's home server, for which the ID token is intended.
Unfortunately, this underlying protocol is not standard OAuth2 or OIDC. I'm not sure we want to publicly document the protocol traces.

On Wed, Aug 19, 2015 at 12:16 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Hi Googlers,

It would be hugely useful if you could capture protocol traces that demonstrate how Google actually uses the “azp” claim in cases where the “azp” and “aud” values differ.  Ideally, I'd like to see actual protocol traces, including the Authentication Request, the Authentication Response, and both directions of any the communication between the Client that made the request to the OP and any other Clients that it also sends the resulting token(s) to. Among other things, that would also answer OAuth-y questions like which Client ID is being used for client authentication to the OP when more than one client is involved.

The Connect text about “azp” is currently both ambiguous and contradictory.  This data would be of a huge help to us for sorting this out during the current errata round.

                                                                Thanks a bunch,
                                                                -- Mike


_______________________________________________
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%7c836d72deda5d482c47e908d2a92a1d41%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7uvAkt5fiquNc%2bOVCQir5UvBmFs%2bpyCE0LiqSs14d%2bY%3d>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150820/fa522b6e/attachment.html>