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

[Adam Dawes]

+mengcheng

On Thu, Aug 20, 2015 at 9:03 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

> 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> 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>
> 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
> 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/db43c40d/attachment.html>