Discussion:
[OAUTH-WG] Initial Client Credential - Dynamic Registration
(too old to reply)
Phil Hunt
2013-05-24 20:02:58 UTC
Permalink
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
***@oracle.com
Richer, Justin P.
2013-05-24 21:01:29 UTC
Permalink
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 <***@oracle.com<mailto:***@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/>
***@oracle.com<mailto:***@oracle.com>
John Bradley
2013-05-24 21:54:47 UTC
Permalink
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.
Post by Richer, Justin P.
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt
2013-05-24 22:16:14 UTC
Permalink
Phil

@independentid
www.independentid.com
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
Post by Richer, Justin P.
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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….
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Nat Sakimura
2013-05-24 23:26:22 UTC
Permalink
=nat via iPhone

May 25, 2013 7:16、Phil Hunt <***@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." <***@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 <***@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.


[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
***@oracle.com





_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2013-05-25 00:06:39 UTC
Permalink
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
Post by Richer, Justin P.
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt
2013-05-25 00:20:29 UTC
Permalink
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
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
Post by Richer, Justin P.
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2013-05-28 14:53:44 UTC
Permalink
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
Post by Phil Hunt
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>
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
Post by Richer, Justin P.
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.
Post by Phil Hunt
I have been struggling with the concept of an initial client
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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....
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
_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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2013-05-28 15:17:19 UTC
Permalink
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.
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
Post by Phil Hunt
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
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
Post by Richer, Justin P.
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt
2013-05-28 17:00:10 UTC
Permalink
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
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
Post by Phil Hunt
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
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
.
Post by John Bradley
Post by Phil Hunt
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.
Post by John Bradley
Post by Phil Hunt
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?
Post by John Bradley
Post by Phil Hunt
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.
Post by John Bradley
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.
Post by John Bradley
Post by Phil Hunt
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.
Post by John Bradley
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2013-05-28 17:14:58 UTC
Permalink
Then pass the auth token as a parameter. RFC6750 already says you can do
that.

-- Justin
Post by Phil Hunt
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
Post by Justin Richer
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
Post by Phil Hunt
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>
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P."
Post by Richer, Justin P.
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.
Post by Phil Hunt
I have been struggling with the concept of an initial client
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
_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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2013-05-28 19:01:38 UTC
Permalink
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.
Then pass the auth token as a parameter. RFC6750 already says you can do that.
-- Justin
Post by Phil Hunt
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
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
Post by Phil Hunt
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
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
Post by Richer, Justin P.
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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
.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
George Fletcher
2013-05-28 19:40:17 UTC
Permalink
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
Post by Phil Hunt
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
Post by Justin Richer
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
Post by Phil Hunt
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>
Post by John Bradley
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.
Post by Nat Sakimura
=nat via iPhone
Post by Phil Hunt
Post by John Bradley
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.
Post by Phil Hunt
Post by John Bradley
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.
Post by John Bradley
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.
Post by John Bradley
John B.
On 2013-05-24, at 5:01 PM, "Richer, Justin P."
Post by Richer, Justin P.
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.
Post by Phil Hunt
I have been struggling with the concept of an initial client
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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.
Post by Phil Hunt
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....
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
_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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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?
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
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.
Post by John Bradley
Post by Richer, Justin P.
Post by Phil Hunt
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.
Post by John Bradley
Post by Richer, Justin P.
-- Justin
Post by Phil Hunt
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Loading...