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

[William Denniss]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150819/edc4ea49/attachment.html>