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
