On 06/06/2013 11:20 AM, Phil Hunt wrote:
As I've said before the initial auth token should nothing to do with
auth. It is simply an assertion given to the developer to distribute
in order to pass on signed claims about the software.
Phil, as I and several others have explained previously, that's not true
at all. It's a token that gives authorization to the registration
endpoint. The fact that you can use it as an assertion to pass along
signed claims is an artifact of it being an OAuth token and an OAuth
token is an opaque string. Please read through the dynamic registration
draft again -- it says absolutely nothing about assertions, signatures,
or claims with regard to this token.
Bearer or not bearer is a distraction. The fact that the contents and
format of this token is out of scope leaves a HUGE interop gap.
The fact that some of us (myself included) are *using* this token to
carry this kind of information is out of scope for the basic
registration spec. I completely agree that there's value in defining
this stuff, but as a separate and complementary spec from registration.
Finally never-mind bearer bias, how are client credentials rotated
interoperably if the only thing rotated is client_secret?
*any* parameter on the client, including the registration_access_token
and any extension parameters, can be rotated on any call to the Read or
Update methods (except for client_id). So if you've got another
mechanism for doing client authentication, you can rotate that, too.
I would say the spec only works for client secrets and/or all-in-one
domain where there is no interop.
Considering I've personally used it across domains and without client
secrets (using jwks_uri to register public keys), I have to empirically
disagree with that statement.
-- Justin
Phil
On 2013-06-06, at 1:53, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
