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
