We have two separate discussions going on. 8-) Phil
@independentid www.independentid.com phil.h...@oracle.com On 2013-06-06, at 10:48 AM, Justin Richer wrote: > I thought we were talking about the registration access token, not the > initial access token? > > -- Justin > > On 06/06/2013 01:48 PM, Phil Hunt wrote: >> This is why this to-MAY-to vs. to-MAH-to distinction around is the initial >> access token an authorization token is important. >> >> The purpose for the initial access token is dramatically different then >> normal access tokens. This is for "registration" and does not constitute >> authentication or authorization. >> >> Therefore, in this case, I do not believe that defining access tokens in the >> broader sense makes this issue clearer. >> >> Registration is a very specific process different than authorization. >> >> This might be a good paper to look at so the group understands why I am >> differentiating authorization from what is happening with initial access: >> http://tools.ietf.org/html/draft-hallambaker-httpauth-00 >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> On 2013-06-06, at 10:37 AM, Justin Richer wrote: >> >>> Interoperability of the processing of OAuth tokens is a separate issue that >>> needs to be solved not just for registration. When it is solved in the >>> wider case, Registration as-is will inherit the solution. >>> >>> So today, if you're using an Initial Access Token (which is optional), then >>> you're locked to whatever process you want to use to verify/validate that >>> token. Since it's just an OAuth token, you've got a number of things that >>> you can do (assertions, introspection, magic). >>> >>> I'd rather we solve the *real* cross-domain issue in the wider case than >>> just try to cram something into registration. >>> >>> -- Justin >>> >>> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>>> >>>>> >>>>> 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. >>>> It depends which case you are using. If the developer is talking to a >>>> single deployment domain and obtains an initial access token and then >>>> ships it with all clients, then sure. In this scenario, the contents are >>>> totally controlled by the local domain. >>>> >>>> I agree. In this case, you don't care about inter-op. The whole >>>> environment is siloed. But then, if this is your case, I'm not sure why >>>> this draft is at the IETF. >>>> >>>> The interoperability case is where a third party generates that assertion >>>> and the deployment domain has to decide to accept it. So you are a >>>> developer and you want to build a client for a Microsoft or Oracle app. >>>> You want to be able to ship that to your customers. You register with the >>>> appropriate publisher and they give you a signed assertion that can be >>>> used as the "Initial Access Token". This token is then accepted by the >>>> deployment domain and then it decides if it trusts the signer or not. >>>> >>>> ===> For this to work, the contents and format of that token MUST be >>>> defined. Otherwise how could we ensure a Microsoft signed assertion >>>> would be accepted by a PingIdentity OAuth server? Or any other >>>> combination of implementations from different vendors/communities? >>>> >>>>> >>>>>> >>>>>> 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. >>>> >>>> [PH] I was reacting to John Bradley's assertion that the spec was narrowly >>>> defined with interop in mind. Yet this mechanism is a key factor being >>>> used to share information about the software. >>>> >>>>> >>>>>> >>>>>> 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> 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> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
