Subject: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.

From: John Bradley <[email-masked]>
Date: Mon, 14 Oct 2013 21:01:12 -0300

A new version of I-D, draft-bradley-stateless-oauth-client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:	 draft-bradley-stateless-oauth-client
Revision:	 00
Title:		 Stateless Client Identifier for OAuth 2
Creation date:	 2013-10-15
Group:		 Individual Submission
Number of pages: 4
URL:             http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00

Abstract:
  This draft provides a method for communicating information about an
  OAuth client through its client identifier allowing for fully
  stateless operation.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Pedro Felix <[email-masked]>
Date: Tue, 15 Oct 2013 10:06:14 +0100

Hi,

Is this applicable to public (non-confidential) clients only? For
confidential clients, the verification of the client_secret doesn't seem to
be addressed by this proposal (token endpoint interactions).
We could however extend it to address this scenario, namely by using
encrypted JWTs with client_secret verification information.

Thanks
Pedro

On Tue, Oct 15, 2013 at 1:01 AM, John Bradley <[email-masked]> wrote:

> URL:
> http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
> Htmlized:
> http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00
>
>
> Abstract:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Oct 2013 07:43:09 -0300

It is intended for confidential clients.

In 2 it states that you may encrypt the JWT.   

If asymmetric authentication using the assertion profile is used the registration endpoint would put the client's public key in the JWT and would not need to encrypt it.

I expect that encrypting the JWT with integrity AES+HMAC would be a good solution for clients using symmetric secrets.  

The exact method for doing this can be determined by the AS as it is a token from the AS to the AS there are no interoperability issues with the symmetric case.

In the case of a client using asymmetric assertion profile authentication it is possible that the registration endpoint is not tightly coupled to the registration endpoint.
A single registration endpoint could issue stateless client_id that are accepted and verified by multiple AS.  In this case the format of the JWT needs standardization for interoperability.

John B.

On 2013-10-15, at 6:06 AM, Pedro Felix <[email-masked]> wrote:

> Hi,
> 
> Is this applicable to public (non-confidential) clients only? For confidential clients, the verification of the client_secret doesn't seem to be addressed by this proposal (token endpoint interactions).
> We could however extend it to address this scenario, namely by using encrypted JWTs with client_secret verification information.
> 
> Thanks
> Pedro
> 
> 
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 21 Oct 2013 05:26:25 +0000

If you have a confidential client using a traditional symmetric secret, from the client's perspective you wouldn't pack the secret into the client_id with this method any more than you would pack it into the client_id using a normal method -- at least as far as the client is concerned, they're two separate and unrelated values, generally treated as opaque. Ideally with a stateless client you'd be using some kind of asymmetric key with the assertion profile or something like that for client auth, and I think that's going to be the most common case for people who are doing a truly stateless server environment, but there are a few other ways you could handle it.

As John points out in another thread, you could encrypt the claims set to the AS's key. This would let you put the secret itself directly inside the client_id without the client being able to muck about with it, and without exposing it to the browser or other agents that get the client_id (which, you must remember, is essentially public information).

Alternatively, you could tie the client ID to the secret by issuing a signed JWT as the client_secret as well, with the client_secret's JWT containing the same subject as the client_id's JWT.

There are probably some other tricks you could do, but these are the cleanest two that come to mind for me. Maybe others can fill in on what those might be.

 -- Justin

On Oct 15, 2013, at 5:06 AM, Pedro Felix <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks
Pedro

On Tue, Oct 15, 2013 at 1:01 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
A new version of I-D, draft-bradley-stateless-oauth-client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

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

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

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Oct 2013 10:21:29 -0700

I am assuming that this draft fits with the dyn reg draft.  It makes the assumption that every single client is somehow potentially different in terms of registration.  This draft encodes the registration values in the JWT so that stateless registration can be achieved.

Dynamic registration takes a different view from client association, in that dynamic registration has no notion of fixed client software releases that are deployed many times. As such there is no fixed registration profile. Every client is potentially different. In contrast Client Association + Software statements, clients are identified as a particular software and are fixed. 

Have I read this correctly?

From a policy perspective, how would a service provider handle registration of clients that are all potentially different? Why would individual clients need to differ in registration (other than in the tokens negotiated with a particular deployment SP)?

Phil

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 21 Oct 2013 17:56:49 +0000

For what it's worth, the latest public dynamic registration working group draft has software_id and software_version fields to allow statements to be made about the fixed client software releases that are deployed many times, of which you speak.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, October 21, 2013 10:21 AM
To: John Bradley
Cc: oauth list
Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-10-14, at 5:01 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

The IETF Secretariat

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Oct 2013 11:02:27 -0700

Yes. But that does not use the signed jwt assertion which "locks" the registration profile.  

Phil

> On Oct 21, 2013, at 10:56, Mike Jones <[email-masked]> wrote:
> 
> For what it’s worth, the latest public dynamic registration working group draft has software_id and software_version fields to allow statements to be made about the fixed client software releases that are deployed many times, of which you speak.
>  
>                                                             -- Mike
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 21 Oct 2013 18:56:32 +0000

As it says in the draft, this could be used with dynamic registration, manual registration, or any other method of registration. How you get the client_id and the nature of the client_id are orthogonal to each other.

As such, you could easily issue this structured/signed stateless client_id in response to a signed software statement presented during either dynamic registration (which really should be a proper extension of dynamic registration). Alternatively, you can issue this client_id from a manual registration step and then you don't need to do a dynamic registration at the AS at all, since the AS can recognize and validate the contents of the client_id (because it's completely stateless).

 -- Justin

On Oct 21, 2013, at 10:21 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>>
 wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

Abstract:

The IETF Secretariat

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 22 Oct 2013 00:49:30 +0000

Phil, I agree with your observations, seem like its screwed up

Phil

@independentid

Abstract:

The IETF Secretariat