Right, and the original question in this part of the thread was "why
bother with an ID token, why not just re-use the access token for both
purposes?"
Torsten's response below was in answer to that -- merging these two
would make the access token non-opaque to the client. This is
undesirable for many reasons. We had this discussion years ago in the
OIDC working group (several times) and came to the same conclusion there
(several times).
Which goes to further the point that the A4C draft is simply re-hashing
work that's already been covered by OIDC, often incompletely and missing
key functionality required for interoperability and security, and adding
nothing new or valuable to the conversation.
-- Justin
On 6/12/2014 9:25 AM, John Bradley wrote:
The Id_token is audienced to the client. It is not sent to a resource server.
In a4c there may be no access token or resource server.
The id_token is not opaque to the client.
John B.
Sent from my iPhone
On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net>
wrote:
Torsten,
nobody suggested that the access token would suddenly not be opaque to
the client.
The question therefore is whether the id token is not opaque to the
client. Is that the assumption?
On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
the access token is opaque to the client. That's great! Let's keep it
that way.
Ciao
Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
