Phil, The OAuth token used authorize access to the registration endpoint( if one is required) would be issued by the registration server via some method eg cut and paste from a developer portal, email or perhaps via OAuth to a Developer API management application. That is declared out of scope because the token is optional and there are lots of ways developers can get them.
I see it as a OAuth access token with some scopes attached to it like any other access token. You seem to be thinking it is something else. I don't understand what third party would be issuing these tokens. You seem to have a use case in mind but I don't think I understand it. John B. On 2013-05-24, at 7:26 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > > =nat via iPhone > > May 25, 2013 7:16、Phil Hunt <phil.h...@oracle.com> wrote: >> >> >> On 2013-05-24, at 2:54 PM, John Bradley wrote: >> >>> I agree with Justin. >>> >>> If you want tight authentication on the AS that issues the tokens we can >>> use OAuth for that with short lived tokens granted based on a SAML SSO , >>> PIV card or whatever floats your boat for authentication. >> >> [PH] I don't want tight authn. This is *registration*. Yet we are pretending >> we are authenticating when we aren't. > > It is not authentication. > It is an access authorization to this API. > >> >>> How the tokens are issued to the OAuth client doing the registration (not >>> the OAuth client being registered) is up to the AS running the registration >>> endpoint. They are OAuth tokens and you can cram an assertion in them if >>> you like. >> >> [PH] This is nothing to do with my point here. >>> >>> Dynamic registration for OAuth should be built with OAuth! >> [PH] Well I was going to bring that up but didn't want to freak people out. >> The idea you refer to was why not use oauth to issue an access token to >> registration server. But that just makes people's head explode. >> >>> >>> John B. >>> On 2013-05-24, at 5:01 PM, "Richer, Justin P." <jric...@mitre.org> wrote: >>> >>>> 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> >>>> 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] 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. >> >> [PH] At minimum, as a UUID it is self asserted and only identifies a common >> unique value shared between instances of a particular piece of software. >> >> But there is nothing saying it can't be a JWT signed assertion serving the >> function of passing on signed client metadata. >> >> The *big* difference is that the processing of the token occurs within the >> registration endpoint. The ONLY endpoint that should accept this. >> >> When you stick it in the HTTP Auth header it will likely get processed by >> the platform security system which then has to have special handling code to >> intercept this custom, undefined, unprofiled token. >> >> Of course, you could just bypass platform security on everything…. >>>> >>>>> >>>>> 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. >> >> [PH] What you are passing in Blue Button is a software assertion. It's not >> an authorization or an authentication. Authorization would have to be >> issued locally. Authentication, could be federated, but there are no authn >> statements are there. So it is a bearer software assertion. The only >> reason it is better than UUID is that we can evaluate trust of a third party >> with regards to the statements contained. >>>> >>>>> >>>>> 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. >> >> [PH] I think the whole point of having an "initial authentication >> assertion" is that it is federated -- generated by third party. Why would I >> bother if it is local? >>>> >>>>> >>>>> 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. >> >> [PH[ NO IT IS NOT. The token is issued by a third party provider. Besides >> when someone says "OAuth Token" I take that to mean an ACCESS token. If it >> is anything else it is just a JWT or SAML 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. >> >> [PH} Sure what you suggest can and will work. But it is 10x more complex >> architecturally. >>>> >>>>> >>>>> 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. >> >> [PH] >> 1. What rules do you need around a UUID? It is JUST a unique identifier. >> 2. If an assertion, how is it *any* different from intial client assertion >> other than the component of the server that must process it? >> >> As I said, if you make it part of authentication, then complexity increases >> and therefore we would have to tightly profile the assertion so that token >> authentication system will accept these federated tokens. >> >> If you leave it as part of software_id, then we can be more informal (to a >> point). >> >> I can't help this, it is just the way servers are made. The horse has left >> the barn as John says. >>>> >>>> -- Justin >>>> >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
