Hi Justin, Hi Mike,
thanks for updating the document so quickly.
I have re-read the new version and I have a few minor comments.
You write: The following client metadata fields are defined by this
specification. All client metadata fields are OPTIONAL.
I guess you mean Optional to implement
You are correct. Just adding to access token would make a lot of devs happy and
that certainly should be discussed.
Two requirements issues:
1. A key use case is passing auth ctx only. An access token means asking for
consent to access something. This causes many sites to loose new users.
Hannes,
I’ll clarify the software statement and let Mike/Justin respond for the rest.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jun 5, 2014, at 12:42 AM, Hannes Tschofenig hannes.tschofe...@gmx.net
wrote:
Hi Justin, Hi Mike,
thanks for updating the document so
Can't agree more with the peril of overloading auth information into an access
token.
On Thursday, June 5, 2014 11:05 AM, Mike Jones michael.jo...@microsoft.com
wrote:
Hannes, the Access Token and ID Token do quite different things and have
different structures and properties. The Access
+1
the access token is opaque to the client. That's great! Let's keep it that way.
Am 05.06.2014 um 21:20 schrieb Bill Mills wmills_92...@yahoo.com:
Can't agree more with the peril of overloading auth information into an
access token.
On Thursday, June 5, 2014 11:05 AM, Mike Jones
It’s great but some ways but also very limiting if you are counting on certain
requirements to be represented in the access token
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org
Examples?
Am 05.06.2014 um 21:42 schrieb Anthony Nadalin tony...@microsoft.com:
It’s great but some ways but also very limiting if you are counting on
certain requirements to be represented in the access token
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
No, it's great exactly *because* you can represent things in the access token
that make sense for your app/domain and it stays opaque to the parties who
shouldn't care: the clients. Access tokens aren't opaque to the AS (or PR),
because of OAuth's flexibility of token formats you can use what
Delegation
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 5, 2014 12:45 PM
To: Anthony Nadalin
Cc: Bill Mills; Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Examples?
Am 05.06.2014 um 21:42 schrieb Anthony
If you need user info based on an access token the introspection endpoint is
the right way to go. Even so, there's issues with using an access token as an
authenticator and this is a major reason why OpenID is the right way to go for
authn.
On Thursday, June 5, 2014 12:42 PM, Anthony Nadalin
A core issue for me is that authentication and access are two separate
functions. Some clients want authentication context only. Some want access
only, some want both.
If you combine both complexity ensues (such as loss of opaqueness, needing
introspection, etc etc).
Phil
Looking at the latest draft
http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-03 it is better.
As far as I can see he deltas from Connect Basic profile are:
1 A new response_type code_id_token (I think the similarity to the code
id_token response_type may cause some confusion but that
Using structured access tokens to do delegation or convey other claims to the
RS can and should be separate from the assertions delivered to the client.
The tokens will have different audiences and if using Proof of Possession
different presenter key material.
Using one token for both things
13 matches
Mail list logo
