Subject: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Nov 2013 18:32:29 +0100

Hi John,
Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of the 
stateless client was raised since there was the argument in the air that 
the current OAuth 2.0 RFC requires clients to be stateless due to the 
nature of the client identifier.

It seems that you have found a way to make the client stateless with 
regard to the client identifier (i.e., that the authorization server 
does not need to store information about the client) by dumping state 
information in the client identifier itself. In your case you use a JWT, 
which is clever.

Since RFC 6749 explicitly says that the client identifier string size is 
left undefined  and that the client should avoid making assumptions 
about the identifier size I don't see a problem with the proposed approach.

Now, there is one issue that I am wondering about. The client identifier 
itself is not sufficient for authorizing the client (for confidential 
clients). Instead, there is typically the need to have a secret. Now, 
the secret is not conveyed in the JWT, at least not in the way you have 
define it. You could of course do that and there is a document that 
provides prior art, see http://www.ietf.org/rfc/rfc5077
The story essentially is that the structure (JWT in your case) includes 
the key but of course then you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least a 
digital signature or a keyed message digest for the JWT since otherwise 
there is the risk that the client changes some of the parameters to 
impersonate someone?

A few other questions:

* You write:
"The issuer SHOULD sign the JWT with JWS in such a way that the 
signature can be verified by the authorization server.
"

I believe what you want to say is the following: The authorization 
creates the client identifier (using the JWT) and the client does not 
parse the received content since it treats it as opaque. However, the 
authorization server MUST be able to process and verify received client 
identifiers it previously created, which requires to apply cryptographic 
processing when a JWT is signed (using a JWS) and when a JWT is 
encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for 
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes it 
easier to find the document.

* You write:
"
The issuer MAY encrypt the JWT with JWE.
"

I think you want to be stronger by saying that JWE MUST be used when the 
authorization server wants to apply confidentiality protection of the 
JWT. While the authorization server could use other techniques as well 
the purpose of the document is to describe one way to accomplish the 
goal and therefore it makes sense to be specific.

I would even go as far as suggesting specific algorithms to use, as an 
example.

* Although not stated directly I believe you allow the client identifier 
to be created by a party other than the authorization server. While this 
would theoretically make sense wouldn't it be useful to just assume that 
the issuer is the authorization server?

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Fri, 1 Nov 2013 15:18:00 -0300

The client_id would continue to be opaque to the client as it is now.  The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity if it is using a symmetric key (probably the simplest thing if we are talking about a single registration endpoint paired with a single AS)  In more complicated scenarios where perhaps a group of AS share a single registration endpoint you probably want to use asymmetric signature  then asymmetric encryption + integrity.     Those are deployment decisions that need to be documented but can be transparent to teh client.

Sorry to my mind it is obvious that the JWT would be integrity protected/signed for all clients including clients using asymmetric authentication to the token endpoint, and and signed+encrypted+integrity for clients using symmetric authentication.   That can be made clearer.

It might make sense to assume the issuer is just the AS but the AS can do that without the benefit of a spec now, as there is no interoperability issue.

The spec defining the JWT structure and signing and encryption methods has the most benefit when you don't have such a tight coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the existing registration spec.

I am OK with strengthening the wording on signing/integrity protecting and encryption.  eg if a symmetric key is included the JWT MUST be encrypted.

I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future.

Thanks for giving it a read, see you Sunday I expect.

John B.

On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig <[email-masked]> wrote:

> In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier.
> 
> It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever.
> 
> Since RFC 6749 explicitly says that the client identifier string size is left undefined  and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach.
> 
> Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077
> The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob.
> 
> In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone?
> 
> A few other questions:
> 
> * You write:
> "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server.
> "
> 
> I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE).
> 
> (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].)
> 
> * You should submit the document as draft-bradley-oauth; this makes it easier to find the document.
> 
> * You write:
> "
> I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific.
> 
> I would even go as far as suggesting specific algorithms to use, as an example.
> 
> * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server?
> 
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Nov 2013 19:49:06 +0100

Hi John,

thanks for the super-quick response.

Am 01.11.13 19:18, schrieb John Bradley:
> The client_id would continue to be opaque to the client as it is now.
> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
> provide integrity if it is using a symmetric key (probably the
> simplest thing if we are talking about a single registration endpoint
> paired with a single AS)  In more complicated scenarios where perhaps
> a group of AS share a single registration endpoint you probably want
> to use asymmetric signature  then asymmetric encryption + integrity.
> Those are deployment decisions that need to be documented but can be
> transparent to teh client.

Maybe it would be good to state that in the document that this is a 
possible option without introducing further complications (other than 
the verification procedure is different). If the AS signs the JWT then 
it just needs to compare whether the issuer field matches what it had 
previously put in there. If someone else signs the JWT then it needs to 
check with some trust anchor store or something similar whether it 
trusts that specific issuer.

>
> Sorry to my mind it is obvious that the JWT would be integrity
> protected/signed for all clients including clients using asymmetric
> authentication to the token endpoint, and and
> signed+encrypted+integrity for clients using symmetric
> authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there 
are benefits in doing so.

>
> It might make sense to assume the issuer is just the AS but the AS
> can do that without the benefit of a spec now, as there is no
> interoperability issue.
>
> The spec defining the JWT structure and signing and encryption
> methods has the most benefit when you don't have such a tight
> coupling between registration and AS.
>
> That is likely why Justin and I didn't think a spec was necessary for
> the simple case other than to show people this is possible with the
> existing registration spec.

I think there is value in providing that information for implementers 
even though it does not require new extensions or so.

>
> I am OK with strengthening the wording on signing/integrity
> protecting and encryption.  eg if a symmetric key is included the JWT
> MUST be encrypted.

Cool.
> algorithm agility in the future.
OK.

> Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. 
Derek will run the show.

Ciao
Hannes

>> Hi John, Hi all,
>> In the dynamic client registration conference calls the topic of
>> the stateless client was raised since there was the argument in the
>> air that the current OAuth 2.0 RFC requires clients to be stateless
>> due to the nature of the client identifier.
>>
>> It seems that you have found a way to make the client stateless
>> with regard to the client identifier (i.e., that the authorization
>> server does not need to store information about the client) by
>> dumping state information in the client identifier itself. In your
>> case you use a JWT, which is clever.
>>
>> Since RFC 6749 explicitly says that the client identifier string
>> size is left undefined  and that the client should avoid making
>> assumptions about the identifier size I don't see a problem with
>> the proposed approach.
>>
>> Now, there is one issue that I am wondering about. The client
>> identifier itself is not sufficient for authorizing the client (for
>> confidential clients). Instead, there is typically the need to have
>> a secret. Now, the secret is not conveyed in the JWT, at least not
>> in the way you have define it. You could of course do that and
>> there is a document that provides prior art, see
>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the
>> structure (JWT in your case) includes the key but of course then
>> you have to encrypt the entire blob.
>>
>> In the case of public clients wouldn't you want to mandate at least
>> a digital signature or a keyed message digest for the JWT since
>> otherwise there is the risk that the client changes some of the
>> parameters to impersonate someone?
>>
>> A few other questions:
>>
>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way
>> that the signature can be verified by the authorization server. "
>>
>> creates the client identifier (using the JWT) and the client does
>> not parse the received content since it treats it as opaque.
>> However, the authorization server MUST be able to process and
>> verify received client identifiers it previously created, which
>> requires to apply cryptographic processing when a JWT is signed
>> (using a JWS) and when a JWT is encrypted (using a JWE).
>>
>> * You write: " The issuer MAY encrypt the JWT with JWE. "
>>
>> I think you want to be stronger by saying that JWE MUST be used
>> when the authorization server wants to apply confidentiality
>> protection of the JWT. While the authorization server could use
>> other techniques as well the purpose of the document is to describe
>> one way to accomplish the goal and therefore it makes sense to be
>> specific.
>>
>> * Although not stated directly I believe you allow the client
>> identifier to be created by a party other than the authorization
>> server. While this would theoretically make sense wouldn't it be
>> useful to just assume that the issuer is the authorization server?
>>
>> Ciao Hannes _______________________________________________ OAuth
>> mailing list [email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 5 Nov 2013 06:37:47 +0900

Since the client_id is supposed to be opaque, it would probably be better
to JWE encrypt (note: all JWE encryption are integrity protected as well)
by the authorization server upon issuing it to the client. This way, we
have exactly one way of doing the things, and it works for both symmetric
and asymmetric case.

I see this more useful in the case of symmetric client secret.

If the client were just using public key crypto to authenticate itself to
the server, using the URI of the location of the client metadata as the
client_id would suffice.

This has an advantage of smaller client_id.

2013/11/2 Hannes Tschofenig <[email-masked]>

> possible option without introducing further complications (other than the
> verification procedure is different). If the AS signs the JWT then it just
> needs to compare whether the issuer field matches what it had previously
> put in there. If someone else signs the JWT then it needs to check with
> some trust anchor store or something similar whether it trusts that
> specific issuer.
>
>
>
>
> I think there is value in providing that information for implementers even
> though it does not require new extensions or so.
>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Nov 2013 21:46:23 +0000

Since the client isn't really supposed to be poking around inside of the client_id anyway, I think that JWS is a reasonable starting place, with JWE if you want to actively hide something inside of the client_id from the client (and browser and other parties that see the client_id). Most of the stuff that's tied to a client's configuration isn't that sensitive, in my opinion.

Also, there are other ways to have a symmetric client secret that's stateless beyond packing it into the client_id here. For one, since client_secrets are also opaque to the client, you could just issue a client_secret that's a signed JWT in its own right (or some other signed blob), letting the AS check the signature but the client merely presenting it as a normal client_secret. Alternatively, you could issue a bearer assertion and accomplish the same thing. Both of these would still need to be communicated to the client along side its client_id, the trick is coming up with a mechanism whereby the AS can recognize it.

 -- Justin

On Nov 4, 2013, at 1:37 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

Since the client_id is supposed to be opaque, it would probably be better to JWE encrypt (note: all JWE encryption are integrity protected as well) by the authorization server upon issuing it to the client. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case.

If the client were just using public key crypto to authenticate itself to the server, using the URI of the location of the client metadata as the client_id would suffice.

2013/11/2 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Hi John,

Maybe it would be good to state that in the document that this is a possible option without introducing further complications (other than the verification procedure is different). If the AS signs the JWT then it just needs to compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT then it needs to check with some trust anchor store or something similar whether it trusts that specific issuer.

It would be good to say that because the effort is rather low and there are benefits in doing so.

I think there is value in providing that information for implementers even though it does not require new extensions or so.

Cool.

I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.

Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. Derek will run the show.

Ciao
Hannes

John B.

On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<[email-masked]<mailto:[email-masked]>> wrote:

Hi John, Hi all,

A few other questions:

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

I would even go as far as suggesting specific algorithms to use, as
an example.

Ciao Hannes _______________________________________________ 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

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Nov 2013 21:48:10 +0000

We need to avoid encoding secrets and authentication with client_id as authentication is not part of our mission

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

Cool.

Ciao
Hannes

John B.

A few other questions:

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 5 Nov 2013 06:55:17 +0900

2013/11/5 Richer, Justin P. <[email-masked]>

>  Since the client isn't really supposed to be poking around inside of the
> client_id anyway, I think that JWS is a reasonable starting place, with JWE
> if you want to actively hide something inside of the client_id from the
> client (and browser and other parties that see the client_id). Most of the
> stuff that's tied to a client's configuration isn't that sensitive, in my
> opinion.
>

It may or may not. It depends, really. Switching between encrypted and just
signed depending on the cases seems to be a bit of overhead, though I agree
that signing is a bit easier.

>
>  Also, there are other ways to have a symmetric client secret that's
> stateless beyond packing it into the client_id here. For one, since
> client_secrets are also opaque to the client, you could just issue a
> client_secret that's a signed JWT in its own right (or some other signed
> blob), letting the AS check the signature but the client merely presenting
> it as a normal client_secret. Alternatively, you could issue a bearer
> assertion and accomplish the same thing. Both of these would still need to
> be communicated to the client along side its client_id, the trick is coming
> up with a mechanism whereby the AS can recognize it.
>

That's probably more reasonable. Linking two JWT with sub claim or
something like that.

>
>   -- Justin
>
>
>
>  On Nov 4, 2013, at 1:37 PM, Nat Sakimura <[email-masked]> wrote:
>
>  Since the client_id is supposed to be opaque, it would probably be
> better to JWE encrypt (note: all JWE encryption are integrity protected as
> well) by the authorization server upon issuing it to the client. This way,
> we have exactly one way of doing the things, and it works for both
> symmetric and asymmetric case.
>
>  If the client were just using public key crypto to authenticate itself
> to the server, using the URI of the location of the client metadata as the
> client_id would suffice.
>
>>> <[email-masked]> wrote:
>>>
>>>  Hi John, Hi all,
>>>>

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Nov 2013 13:56:03 -0800

If the AS is using asymmetric encryption you need to both sign and then encrypt as anyone can encrypt. 

Yes if the client has a TLS cert you could use a jwk_uri to keep the size down.

John B.

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 5 Nov 2013 06:56:50 +0900

See my reply to Justin.

BTW, is not the client authentication one of the pain point for the server
that we want to solve statelessly?

2013/11/5 Anthony Nadalin <[email-masked]>

>  We need to avoid encoding secrets and authentication with client_id as
> authentication is not part of our mission
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Nat Sakimura
> *Sent:* Monday, November 4, 2013 1:38 PM
> *To:* Hannes Tschofenig
> *Cc:* [email-masked] WG
> *Subject:* Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
>
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 5 Nov 2013 06:58:18 +0900

I was assuming that the AS uses symmetric encryption as it is faster and it
just needs to be encrypted and decoded by itself.

2013/11/5 John Bradley <[email-masked]>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Nov 2013 22:01:11 +0000

We have mechanisms to do this it's not in our scope to start to encode the client_id with authentication information

From: Nat Sakimura [mailto:[email-masked]]
Sent: Monday, November 4, 2013 1:57 PM
To: Anthony Nadalin
Cc: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

See my reply to Justin.

BTW, is not the client authentication one of the pain point for the server that we want to solve statelessly?

2013/11/5 Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
We need to avoid encoding secrets and authentication with client_id as authentication is not part of our mission

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nat Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

Cool.

Ciao
Hannes

John B.

A few other questions:

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Nov 2013 14:05:28 -0800

The method the AS uses to identify the client is within the scope of the WG.  We have several drafts that relate to that topic of extending that mechanism. 

What we are discussing is how best to do that securely without requiring the AS to issue and maintain per client passwords.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Nov 2013 14:06:01 -0800

So how is a stateless client able to do the authorize flow?  How does the server know about the redirect_url?  Is it wide open?

Still would like to hear more about this.  Sometimes attacking the problem from a different direction leads to an innovative conclusion.

Still I share the concerns of Tony and binding authentication into client_id.

Phil

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

On 2013-11-04, at 1:58 PM, Nat Sakimura <[email-masked]> wrote:

> I was assuming that the AS uses symmetric encryption as it is faster and it just needs to be encrypted and decoded by itself. 
> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Nov 2013 22:10:24 +0000

Identification is fine as long as it remains opaque and not specific to any format. Authentication remains out of scope

From: John Bradley [mailto:[email-masked]]
Sent: Monday, November 4, 2013 2:05 PM
To: Anthony Nadalin
Cc: Nat Sakimura; Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

John B.

On Nov 4, 2013, at 1:48 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

Cool.

Ciao
Hannes

John B.

A few other questions:

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Nov 2013 22:16:54 +0000

The redirect URI is built into the structure of the client_id that the client passes that the AS can parse and check. Think of it as effectively using a structure analogous the software statement as the client_id itself, which you independently proposed as part of your client association draft's discussion sections (for transient clients in your use case, stateless auth servers in this use case).

Authentication of the client is separate, the open question is how people want to communicate the client's authentication credentials to the client in a way that the AS can later recognize. Some people were getting hung up on stuffing the client secret itself into the client_id, in which case you'd need to encrypt the client_id's structure to hide the secret. There are plenty of alternatives though, including just not using client secrets for stateless auth servers (where they don't make as much sense anyway).

 -- Justin

On Nov 4, 2013, at 2:06 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>>
 wrote:

Phil

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

On 2013-11-04, at 1:58 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

2013/11/5 John Bradley <[email-masked]<mailto:[email-masked]>>
If the AS is using asymmetric encryption you need to both sign and then encrypt as anyone can encrypt.

John B.

Cool.

Ciao
Hannes

John B.

Hi John, Hi all,

A few other questions:

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Nov 2013 14:22:31 -0800

If you read the draft the redirect URI and other parameters are encoded into the JWT assertion. 

What we are proposing is using an assertion/token as the client_id that assertion cannot be a bearer assertion for confidential clients, that would be inssecure.
IT needs to be some sort of proof of possession assertion/token.   There are several ways to do proof of possession one is including a public key and the other is encrypting a symmetric key.

The option I didn't include is using some sort of key derivation mechanism, DH etc so that you don't need to encrypt if using a symmetric password.

Symmetric passwords have all sorts of problems.   A static assertion without PoP has similar problems with securing it in the client.

For reference the sort of compromises I am concerned about are already starting to happen.
http://blog.programmableweb.com/2013/11/04/why-the-attack-on-buffer-was-a-serious-wake-up-call-for-the-web/

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Nov 2013 14:31:10 -0800

Yes we are talking about identification rather than authentication though most people conflate the two.  (I know you don't that is why you are Dr Secure)

We need to have the client identify itself via an assertion (in my proposal carried as the client_id parameter,  If we modify OAuth it could be a separate parameter though I don't think that is necessary)  and a symmetric or asymmetric proof of possession mechanism so that theft of the assertion will not allow the attacker to use it to exchange code or refresh_token for access tokens.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Nov 2013 14:42:40 -0800

I see. It was buried under "reg".

Phil

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