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 . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
