[Openid-specs-ab] Gudiance on aud vs azp
sakimura at gmail.com
Fri Apr 12 03:26:56 UTC 2013
Agreed with your assessment.
Token requesting party in case 3 may kick in when audit tracing becomes
important. Until now, we have pretty much been concerned with application
use cases, but it probably is a good time to start looking at audit tracing
and other use cases as well.
=nat via iPhone
Apr 11, 2013 23:56¡¢George Fletcher <gffletch at aol.com> ¤Î¥á¥Ã¥»©`¥¸:
As I was working on some possible text for azp, I realized I have some
questions around aud as well. I figure there has to be some general
consensus about when and how to use them so figured I'd ask on the list
rather than filing a ticket.
I can see a couple of use cases for these fields in the id_token and the
values they contain seem like they can change depending on the context.
1. id_token used only by the client and never presented back to the AS or
aud = client_id of the requesting client
azp = not really needed at all
2. id_token used by the client but also presented to the AS for session
management or bootstrapping endpoints
aud = ??? (seems like it should be the identifier of the AS)
azp = client_id of the requesting client
3. id_token requested by a client and then presented by another client to
aud = identifier representing the endpoint that will receive the
azp = identifier of the client presenting the id_token
??? = no mention of the actual requesting client (is this needed?)
Other use cases?
For me, I'd prefer to collapse use cases 1 and 2 and require azp to be the
client_id of the requesting client and aud be the identifier of the AS or
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab