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

From: Phil Hunt <[email-masked]>
Date: Fri, 24 May 2013 13:02:58 -0700

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 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
2.  The assertion isn't an authentication, but rather signed client metadata.
3.  The bearer assertion is easily copied. Thus the server should only trust this as metadata
4.  It ends up performing the same role as software_id

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.

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.

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.

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.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 24 May 2013 21:01:29 +0000

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 <[email-masked]<mailto:[email-masked]>>
 wrote:

   credential in the form of an OAuth 2.0 [RFC6749<http://tools.ietf.org/html/rfc6749>] access token in

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.

That's fine. Not all OAuth tokens are authentication assertions today, and this is just another OAuth token.

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.

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.

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.

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.

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.

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.

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/>
[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 24 May 2013 17:54:47 -0400

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.
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.  

Dynamic registration for OAuth should be built with OAuth!  

John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P." <[email-masked]> wrote:

> On May 24, 2013, at 4:02 PM, Phil Hunt <[email-masked]>
>  wrote:
> 
>> [email-masked]
> [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 24 May 2013 15:16:14 -0700

Phil

@independentid
www.independentid.com
[email-masked]

> 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 authentic…

[PH] I don't want tight authn. This is *registration*. Yet we are pretending we are authenticating when we aren't.

> 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 c…

[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.

>> 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 part…

[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….
>> 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 solv…

[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.  
>> 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 wh…

[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?  
>> 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.  
>> 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 exten…

[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.

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 25 May 2013 08:26:22 +0900

=nat via iPhone

May 25, 2013 7:16、Phil Hunt <[email-masked]>  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]  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.

 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.

 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.

 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.

 *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
 [email-masked]

---

From: John Bradley <[email-masked]>
Date: Fri, 24 May 2013 20:06:39 -0400

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.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 24 May 2013 17:20:29 -0700

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
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 May 2013 10:53:44 -0400

In BB+, our OAuth tokens are federated because we're doing federated 
OAuth using signed/structured tokens and introspection endpoints that 
the AS and PR know what to do with. We're fundamentally using the 
initial access token as an authorization for calling the endpoint and 
triggering special privileges, and in order to process that 
authorization we've specified how to parse the token as an assertion and 
do discovery and binding to various components of that assertion. But as 
far as the protocol is concerned, it's an authorization to the endpoint.

There is absolutely no reason that I can think of to limit it to just 
this kind of complicated scenario. You can use whatever means you want 
to get the initial registration token into the client software, and the 
registration endpoint can use whatever means you want to validate the 
token.

You're absolutely right that if you use the token to push information 
around, you're going to need to specify a lot more in order to make it 
interoperable. This is precisely the reason that I want to keep things 
opaque at the dyn reg spec level, just like OAuth keeps things opaque at 
its own level. If you also want to do something fancy with that token, 
like carry an assertion, you can do it precisely because it is an 
otherwise opaque OAuth token.

  -- Justin

On 05/24/2013 08:20 PM, Phil Hunt wrote:
> 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 <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> 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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>
>>>
>>> =nat via iPhone
>>>
>>> May 25, 2013 7:16?Phil Hunt <[email-masked] 
>>> <mailto:[email-masked]>>  wrote:
>>>>
>>>>
>>>>> 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.
>>>>
>>>>> 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]  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." <[email-masked] 
>>>>> <mailto:[email-masked]>> 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.
>>>>>>
>>>>>>> I have been struggling with the concept of an initial client 
>>>>>>> credential covered in the current draft (rev 10):
>>>>>>>     credential in the form of an OAuth 2.0 [RFC6749  <http://tools.ietf.org/html/rfc6749>] access token in
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>>>> 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]
>>>> 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.
>>>>
>>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Tue, 28 May 2013 11:17:19 -0400

OK that makes a bit more sense.  What BB+ is doing with federated tokens is supported by Dynamic Registration but not part of it.
I think the federated OAuth tokens for access to the Registration Endpoint is out of scope for this spec.   

I agree that federated access tokens for OAuth are something that generally needs profiling, but is a larger and more general issue.

Nothing in Dynamic Registration requires that the access tokens be anything other than access tokens issued by the AS providing the Registration endpoint.

John B.

On 2013-05-28, at 10:53 AM, Justin Richer <[email-masked]> wrote:

> In BB+, our OAuth tokens are federated because we're doing federated OAuth using signed/structured tokens and introspection endpoints that the AS and PR know what to do with. We're fundamentally using the initial access token as an authorization for calling the endpoint and triggering special privileges, and in order to process that authorization we've specified how to parse the token as an assertion and do discovery and binding to various components of that assertion. But as far as the protocol is concerned, it's an authorization to the endpoint.
> 
> There is absolutely no reason that I can think of to limit it to just this kind of complicated scenario. You can use whatever means you want to get the initial registration token into the client     software, and the registration endpoint can use whatever means you want to validate the token. 
> 
> You're absolutely right that if you use the token to push information around, you're going to need to specify a lot more in order to make it interoperable. This is precisely the reason that I want to keep things opaque at the dyn reg spec level, just like OAuth keeps things opaque at its own level. If you also want to do something fancy with that token, like carry an assertion, you can do it precisely because it is an otherwise opaque OAuth token. 
> 
>  -- Justin 
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 28 May 2013 10:00:10 -0700

Http auth is not the place to be passing non-standard assertions where tighter interop is needed. 

Using a parameter is better suited for this. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 May 2013 13:14:58 -0400

Then pass the auth token as a parameter. RFC6750 already says you can do 
that.

  -- Justin

On 05/28/2013 01:00 PM, Phil Hunt wrote:
> On 2013-05-28, at 7:53, Justin Richer <[email-masked] 
>> authorization we've specified how to parse the token as an assertion 
>> and do discovery and binding to various components of that assertion. 
>> But as far as the protocol is concerned, it's an authorization to the 
>> endpoint.
>>
>> this kind of complicated scenario. You can use whatever means you 
>> want to get the initial registration token into the client software, 
>> and the registration endpoint can use whatever means you want to 
>> validate the token.
>>
>> around, you're going to need to specify a lot more in order to make 
>> it interoperable. This is precisely the reason that I want to keep 
>> things opaque at the dyn reg spec level, just like OAuth keeps things 
>> opaque at its own level. If you also want to do something fancy with 
>> that token, like carry an assertion, you can do it precisely because 
>> it is an otherwise opaque OAuth token.
>>
>>  -- Justin
>>
>>> 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.
>>>
>>> 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.
>>>
>>>> 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.
>>>>
>>>>> May 25, 2013 7:16、Phil Hunt <[email-masked] 
>>>>>>> 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.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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." 
>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>>>>> _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.
>>>>>>
>>>>>> 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.
>>>>>>>>
>>>>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>>>> 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 
>>>>>>>>> That said, if there is a case to adopt strict rules here too, 
>>>>>>>>> I am open.
>>>>>>>>
>>>>>>>> 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]

---

From: John Bradley <[email-masked]>
Date: Tue, 28 May 2013 15:01:38 -0400

Yes it can be passed as appropriate.   That is also one reason why we separated the client_secret_post and client_secret_basic in registration, for RS and clients who may have a limited ability to deal with headers.

On 2013-05-28, at 1:14 PM, Justin Richer <[email-masked]> wrote:

> Then pass the auth token as a parameter. RFC6750 already says you can do that.
> 
>  -- Justin
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 28 May 2013 15:40:17 -0400

As Justin and John have said... I think all that the spec is saying is 
that the registration endpoint can be an OAuth2 protected resource. In 
that sense, the Authorization header is the correct place for this token 
as defined by RFC 6750. Any additional semantics of how to use the 
Authorization token are out-of-scope for the spec. If there are 
additional capabilities or semantics that are desired, then a profile of 
the dyn reg spec can be created to cover those semantics.

As it stands now, if an authorization token is specified, or the AS 
requires one, then the AS is responsible for validating the token and 
either providing or rejecting access to the endpoint. That makes sense 
to me and fits fine with the use of the Authorization header.

Thanks,
George