I completely disagree with this assessment. The latest draft (which was just posted) has new language describing what this token is and what it's for, and I hope that will clear things up. But even so, let me try to address your concerns in-line.
On May 24, 2013, at 4:02 PM, Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote: I have been struggling with the concept of an initial client credential covered in the current draft (rev 10): The Client Registration Endpoint MAY accept an initial authorization credential in the form of an OAuth 2.0 [RFC6749<http://tools.ietf.org/html/rfc6749>] access token in order to limit registration to only previously authorized parties. The method by which this access token is obtained by the registrant is generally out-of-band and is out of scope of this specification. The Client Registration Endpoint is an OAuth Protected Resource. This token is a means for authorizing calls to the endpoint. Can you use it for other things? Sure, just like you can use OAuth tokens for other things (passing data about authentication, for instance). But fundamentally, it's just another token that's scoped to one endpoint for a specific purpose. The use case is very important since it opens the door for a way for trusted entities to sign assertions that could be accepted by a set of deployed authorization servers. For potential software API developers (e.g. Oracle CRM), the developer could potentially register with Oracle CRMs registration service manually, and obtain a signed assertion for use in their client software. Upon initiating dynamic registration, the client software would present the assertion as its initial authorization in the HTTP Authorization header as Justin describes above. While this has worked in practice so far, I am concerned about this assertion being presented in this way. The authentication header has special meaning to many servers. Depending on implementation architecture, the authorization header will first be intercepted by the authentication components in the server. Here's where I get worried. 1. The assertion being presented is not an Authn assertion. There is no "authentication session" tied to the assertion That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token. 2. The assertion isn't an authentication, but rather signed client metadata. If you want to interpret the token as both authorization to call the registration endpoint as well as client metadata, you can do that. But you're going to have to define how that metadata is passed, how it's signed, how it's interpreted, etc. Which, you'll note, is exactly what you can do with an OAuth token already. You can use an OAuth token as an opaque blob, or you can define structure, signatures, etc., to pack information inside of it. If the two always had to be together, then OAuth would be defined with JWTs only and we'd have something that was much less useful. 3. The bearer assertion is easily copied. Thus the server should only trust this as metadata Depends on the kind of client, and with BB+ we've defined a matrix of client types with different policy rules (since we can control policy in BB+ land). Our discovery and registry setup lets us enforce these rules appropriately as well. 4. It ends up performing the same role as software_id Not really. How does software_id (on its own) represent a that the holder is authorized to make this call? You'd have to put rules around software_id saying that it needs to be processed in a particular way, and I think such rules are far too restrictive for this draft. Another difference is that a bearer token isn't generally self-asserted, and it's assumed the registration server will have some means of validating this token, like it would with any OAuth token. It's more like you can use the Initial Registration Token to fulfill the same role that you're suggesting software_id be used for, which, to me, is more of an argument against the more-limited software_id than it is against the existing technology. While I think it is ok for existing implementations to continue with this practice, I would prefer to standardize passing of client software assertion metadata outside of the authentication channel in HTTP. The token in question is fundamentally an authorization mechanism for calling the registration endpoint. I agree there's value in passing client software assertions around, and that we should solve that in an interoperable way, but that's a completely separate question from registration. A further benefit is that the registration endpoint authentication system only has to deal with locally issued credentials. The logic for handling federated client meta data can be isolated to the registration server logic. You can still do that if your registration server is the one generating the initial access token. Normally, the registration endpoint's going to be tightly tied to the authorization server, and whatever process is used to get the initial registration token is going to also be tightly tied to the registration server. My feeling is that if we keep "initial authorization credential" as being passed in the HTTP Authorization header, then strict rules about the contents of the token and the processing rules must be defined so that HTTP server security systems can be extended to support this. It's an OAuth token. You use whatever HTTP security systems that you already have to process OAuth tokens on it. If you also want to use it to tell you something about client metadata, you're going to have to define further processing, yes, because "an OAuth token" doesn't tell you anything about what's inside of it or what the token means -- on purpose. But you'd have to do the same thing with software_id. But nothing is saying that you need to do that, or that it has to be an assertion at all. Maybe you just want to lock down your API to know developers, so you issue them hex blobs to call the API with. Those could expire 5 minutes from when you issued them, if you wanted. Or they could be SAML blobs, or JWTs, or anything else that can pass for an OAuth token. There's no reason any of this should be disallowed by the registration spec, because the registration spec doesn't care. All it cares about is that it's an OAuth token and it's (somehow) validated by the registration endpoint in such a way that the HTTP call to the Registration Endpoint is valid. This is absolutely bog-standard OAuth Protected Resource here. By defining it as an OAuth token (and no further), we immediately gain all of the flexibility and power of OAuth tokens. If we use software_id, and indicate that it can accept a "software registration assertion", we can be more flexible and minimize the processing rules we have to declare in the draft. That said, if there is a case to adopt strict rules here too, I am open. I still think that software_id is really only useful and interoperable in the presence of strict rules, which is why I'm not convinced it belongs in the draft as is and instead belongs in an extension that defines such rules. This draft would be way beyond the two paragraphs that you had spoken of previously, and it would be both useful and interoperable. But it's enough complexity and enough of a very specific corner case that I am not at all comfortable putting that level of processing into the dynamic registration draft. I am willing to put software_id into dynamic registration as a hook to some future-to-be-defined specification that tells you how to validate it and parse it and use it for validating client metadata and tie it to a developer and all that fun stuff -- I don't personally see the utility in that, but I don't think it'd really break anything if it went in and you thought you could use it to bootstrap your process. -- Justin Phil @independentid www.independentid.com<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> _______________________________________________ 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
