We haven't defined the various proof of possession tokens yet. It may be that there are different registration requirements for clients being issued those tokens.
It is possible that the client must have registered and pushed a public key to the AS before it is issued a HoK token. It may be just fine, but I can't certain of that until we define the other token types. What we do know is that what is proposed is in production across multiple providers, and we are gaining experience with it on some of the things that didn't work like using the client's token endpoint credential for updating the registration information. Extensibility is good but the new token types will have there own issues that will need to be addressed in a profile. It is not enough to say any OAuth token type can be used without a profile, because people will come back and say how is that interoperable? Especially if we are issuing HoK tokens to clients we will likely want a way to register the public key of the client. We don't have that yet as there is no asymmetric HoK token yet. Once there is then we do an extension of registration to cover it. We have people going into production soon so we can't wait for every possible token type to be defined. John B. On 2013-06-06, at 4:48 PM, "Manger, James H" <james.h.man...@team.telstra.com> 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. > 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. > > 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. > > > 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. > > -- > 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> 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] > Sent: Thursday, June 06, 2013 11:54 AM > 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 > > 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> 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 .
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
