Re: [OAUTH-WG] Initial Client Credential - Dynamic Registration

[Phil Hunt <[e-mail]>]

The use cases I have heard of from Justin and Morteza at IIW are based on federated scenarios. These are not just locally asserted tokens.

Your assertion that the tokens are local and my assertion they are federated suggests there are things that must be sorted out/understood.

I'm merely implying that if you don't want to profile this, then don't use HTTP Auth to pass the information.  The reason HTTP Auth pushes the inter-op issues is that many deployment architectures have multi-layers of components processing security in a platform.  Thus inter-op has to be well defined.

When the logic is concentrated into just OAuth registration components, we can have looser definition IMHO.  Though others will argue the assertion still needs to be tightly defined.

Phil

@independentid
www.independentid.com
[e-mail]





On 2013-05-24, at 5:06 PM, John Bradley wrote:

> 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 <[e-mail]> wrote:
> 
>> 
>> 
>> =nat via iPhone
>> 
>> May 25, 2013 7:16、Phil Hunt <[e-mail]>  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." <[e-mail]> 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 <[e-mail]>
>>>>>  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
>>>>>> [e-mail]
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>