On 06/06/2013 10:48 AM, Manger, James H wrote:
John,
Why is the circularity of registration any different for a non-bearer
scheme?
A developer browsing a service portal can grab an id & secret, just as
easily as grabbing a bearer token, to configure into an app as the
initial access token.
That's true -- and in that case, they're not doing dynamic registration
and this spec doesn't apply. They're doing static registration, which is
still of course an option.
But there are cases where you want to pre-authorize a developer or tie
together a set of clients, and the Initial Access Token gives you a
mechanism for starting that work. (Though, importantly, it doesn't
specify everything that you'd need in order to do that.)
A client registration endpoint can return an id & secret, just as
easily as returning a bearer token, for the client to use as the
registration access token.
It does, for clients that use them. But not all clients use
client_secret, and forcing all clients to have a client_secret just to
talk to the registration endpoint doesn't fly. OpenID Connect already
tried that approach, and failed, and we need to learn from that mistake
instead of repeating it. What's tricky about this is that it seems like
a perfectly reasonable thing to do on the surface but it falls apart
quickly in implementation.
OAuth 2 defines a JSON format for conveying an access token [RFC6749
"OAuth 2.0" section 5.1. "Issuing an access token: Successful
Response"]. That might be a better syntax for an app to expect when
receiving an initial access token and a registration access token,
given it needs to understand that format for "real" access tokens anyway.
How you get the initial access token is out of scope. You *can* do a
plain old OAuth 2.0 flow and get the Initial Access Token back from the
Token Endpoint with the syntax mentioned here. We didn't adopt that
syntax for the registration endpoint's Registration Access Token
response because it was argued that as a simple bearer token with no
explicit scopes or other properties, a simple string would be
preferable. While I would personally prefer to use the structure from
the Token Endpoint, the Working Group decided (and convinced me) that
locking it down to a simple bearer token in this case (just the
Registration Access Token) is simpler for clients and servers to deal with.
> Having a mandatory-to-implement mechanism in place is certainly useful
Registration supporting the same mechanism an app will use with "real"
access tokens (whatever that is for this AS) would be even more useful.
But what if the app doesn't authenticate to the token endpoint at all?
We can't just throw out an entire class of clients.
-- Justin
--
James Manger
*From:*John Bradley [mailto:ve7...@ve7jtb.com]
*Sent:* Thursday, 6 June 2013 7:22 PM
*To:* Tschofenig, Hannes (NSN - FI/Espoo)
*Cc:* ext Tim Bray; Manger, James H; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
On the face of it I think adding proof of possession aught to be
possible. The hard part will be that those mechanisms assume a
registered client.
I think the trick will be not crating a circular registration problem.
Adding the other token types to the RS will be simple in comparison.
John B.
On 2013-06-06, at 10:57 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<hannes.tschofe...@nsn.com <mailto:hannes.tschofe...@nsn.com>> wrote:
That's fair, John.
Having a mandatory-to-implement mechanism in place is certainly
useful. Pushing stronger security mechanisms to other specifications
is also fine. It would be good to re-read the document to see whether
we can actually fit the currently worked on security mechanisms into
the spec at a later stage or whether there are some problems with the
extensibility story.
Ciao
Hannes
*From:*ext John Bradley [mailto:ve7...@ve7jtb.com <http://ve7jtb.com>]
*Sent:*Thursday, June 06, 2013 11:54 AM
*To:*Tschofenig, Hannes (NSN - FI/Espoo)
*Cc:*ext Tim Bray; Manger, James H; oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
There are a couple of reasons.
One criticism Hannes and others make of OAuth specs is they are not
tightly profiled enough to be interoperable without further out of
band configuration and profiling.
Making registration work with minimal ambiguity was a priority for
Connect and that has carried over.
I am not opposed to having this extended at some point in the future,
once we have a second token type. The new token type should be
available to do updates as well.
The problem is that starting down the HoK route potentially requires a
registered client that may need to be registered to do the registration.
I think that is best left to another spec to sort out the possible
turtles.
So the default needs to be bearer tokens unless registration is
extended by another profile.
John B.
On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<hannes.tschofe...@nsn.com <mailto:hannes.tschofe...@nsn.com>> wrote:
Because bearer tokens have a stable RFC-numbered spec and are widely
implemented and the registration flow as documented seems like it
should work? -T
That's the answer for why there is support for bearer tokens but it is
not the answer to why that's the only supported mechanism.
If we want to support stronger security mechanisms (which the group
has decided to work on already) then we need to have a story on how to
support the other mechanisms as well .
_______________________________________________
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
