[OAUTH-WG] expired hotk spec

[Phil Hunt]

https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

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

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

[Phil Hunt]

I see. It was buried under "reg".

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

On 2013-11-04, at 2:22 PM, John Bradley  wrote:

> 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.
> 
> On Nov 4, 2013, at 2:06 PM, Phil Hunt  wrote:
> 
>> 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
>> phil.h...@oracle.com
>> 
>> On 2013-11-04, at 1:58 PM, Nat Sakimura  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. 
>>> 
>>> 
>>> 2013/11/5 John Bradley 
>>> 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.
>>> 
>>> On Nov 4, 2013, at 1:37 PM, Nat Sakimura  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. 
 
 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 
 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 w

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

[John Bradley]

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.

On Nov 4, 2013, at 2:10 PM, Anthony Nadalin  wrote:

> Identification is fine as long as it remains opaque and not specific to any 
> format. Authentication remains out of scope
>  
> From: John Bradley [mailto:ve7...@ve7jtb.com] 
> Sent: Monday, November 4, 2013 2:05 PM
> To: Anthony Nadalin
> Cc: Nat Sakimura; Hannes Tschofenig; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
>  
> 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.
>  
>  
> On Nov 4, 2013, at 1:48 PM, Anthony Nadalin  wrote:
> 
> 
> We need to avoid encoding secrets and authentication with client_id as 
> authentication is not part of our mission
>  
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
> Sakimura
> Sent: Monday, November 4, 2013 1:38 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
>  
> 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 
> 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.
>  
> 
> 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.
> Unfortun

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

[John Bradley]

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.

On Nov 4, 2013, at 2:06 PM, Phil Hunt  wrote:

> 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
> phil.h...@oracle.com
> 
> On 2013-11-04, at 1:58 PM, Nat Sakimura  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. 
>> 
>> 
>> 2013/11/5 John Bradley 
>> 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.
>> 
>> On Nov 4, 2013, at 1:37 PM, Nat Sakimura  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. 
>>> 
>>> 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 
>>> 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 s

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

[Richer, Justin P.]

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 
mailto:phil.h...@oracle.com>>
 wrote:

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
phil.h...@oracle.com

On 2013-11-04, at 1:58 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> 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.


2013/11/5 John Bradley mailto:ve7...@ve7jtb.com>>
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.

On Nov 4, 2013, at 1:37 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> 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.

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 
mailto:hannes.tschofe...@gmx.net>>
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.


I don't necessarily want to make any 

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-12

[Mike Jones]

-12 addresses a few of the review comments, but not the majority of them.  
Those that it addresses are about "cty" and "typ". For instance, it does 
address Prateek's comment 2 (Why do we need both a "typ" claim and a "typ" 
header name?) and James' comment 7 (The doc redefines the "cty" header 
parameter).  (We no longer have both a "typ" claim and "typ" header parameter; 
"cty" is not redefined.)

The reality is that lately more of my time has gone into addressing the 
numerous JOSE comments, to try to get those documents that we depend upon to a 
stable point, than addressing the relatively small number of JWT comments.  But 
I will try to respond to the four sets of WGLC comments received this week, 
once my prep work for the JOSE meeting on Thursday is done.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Hannes Tschofenig
Sent: Friday, November 01, 2013 12:27 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-12

Hi Mike, Hi all,

I was just trying to find out whether version -12 of the JWT spec addresses 
prior comments and the diff version of the document does not really give that 
indication. To me it seems that version -12 of the document was published to 
update -11 in an attempt to create an alignment with the JOSE work.

I believe it would be useful to respond to the review comments so that we can 
be sure that those had been taken into account (or that they had been rejected 
for a good reason).

Here are the comments I have found:

* Review by James Manger:
http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html

* Review by Mishra Prateek:
http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html

* My own shepherd review:
http://www.ietf.org/mail-archive/web/oauth/current/msg12125.html

Ciao
Hannes

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

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

[Anthony Nadalin]

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

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

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.


On Nov 4, 2013, at 1:48 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:


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

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

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 
mailto:hannes.tschofe...@gmx.net>>
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.


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
mailto:hannes.tschofe...@gmx.net>> wrote:
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 i

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

[John Bradley]

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.


On Nov 4, 2013, at 1:48 PM, Anthony Nadalin  wrote:

> We need to avoid encoding secrets and authentication with client_id as 
> authentication is not part of our mission
>  
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
> Sakimura
> Sent: Monday, November 4, 2013 1:38 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
>  
> 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 
> 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.
>  
> 
> 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
>  wrote:
> 
> 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

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

[Phil Hunt]

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
phil.h...@oracle.com

On 2013-11-04, at 1:58 PM, Nat Sakimura  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. 
> 
> 
> 2013/11/5 John Bradley 
> 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.
> 
> On Nov 4, 2013, at 1:37 PM, Nat Sakimura  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. 
>> 
>> 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 
>> 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.
>> 
>> 
>> 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
>>  wrote:
>> 
>> 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 s

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

[Anthony Nadalin]

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:sakim...@gmail.com]
Sent: Monday, November 4, 2013 1:57 PM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org 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 mailto:tony...@microsoft.com>>
We need to avoid encoding secrets and authentication with client_id as 
authentication is not part of our mission

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

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 
mailto:hannes.tschofe...@gmx.net>>
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.


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
mailto:hannes.tschofe...@gmx.net>> wrote:
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 av

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

[Nat Sakimura]

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 

> 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.
>
> On Nov 4, 2013, at 1:37 PM, Nat Sakimura  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.
>
> 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 
>
>> 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.
>>
>>
>>> 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
>>>  wrote:
>>>
>>>  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 authori

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

[Nat Sakimura]

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 

>  We need to avoid encoding secrets and authentication with client_id as
> authentication is not part of our mission
>
>
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Monday, November 4, 2013 1:38 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
>
>
>
> 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 
>
> 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.
>
>
>
>
> 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
>  wrote:
>
> 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 (fo

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

[John Bradley]

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.

On Nov 4, 2013, at 1:37 PM, Nat Sakimura  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. 
> 
> 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 
> 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.
> 
> 
> 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
>  wrote:
> 
> 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 es

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

[Nat Sakimura]

2013/11/5 Richer, Justin P. 

>  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  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.
>
>  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 
>
>> 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.
>>
>>
>>> 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
>>>  wrote:
>>>
>>>  Hi John, Hi al

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

[Anthony Nadalin]

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

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

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 
mailto:hannes.tschofe...@gmx.net>>
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.


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
mailto:hannes.tschofe...@gmx.net>> wrote:
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
yo

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

[Richer, Justin P.]

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 
mailto:sakim...@gmail.com>> 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.

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 
mailto:hannes.tschofe...@gmx.net>>
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.


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
mailto:hannes.tschofe...@gmx.net>> wrote:

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

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

[Nat Sakimura]

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 

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

[OAUTH-WG] Security Considerations (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote:
> Security Consideration section:
>
>
> I believe the section needs to say two things into addition to the reference
> to the other specifications, which are already included in the security
> consideration section:
>
> a) The specification does not mandate replay protection for the SAML
> assertion usage for neither the authorization grant nor for the client
> authentication. It is an optional feature.

Okay, I'll add some text about that. I think a word or two about it
should go into Interoperability Considerations as well.

> b) There is actually no authentication happening when these SAML assertions
> are used for client authentication and for the authorization grant (in the
> classical definition of authentication). This may be surprising to some why
> typically assume that the client would have to demonstrate proof of
> possession of a secret, which isn't the case here.

I'm not sure I fully understand what you mean. Maybe it's some
semantics around "authentication." Can you explain more or propose
some text?

> It would have been possible to provide more enhanced funtionality (and SAML
> supports this as well) but it is not provided in the specification. Maybe a
> future specification will provide that functionalility. I think it is worth 
> pointing out.

Can you give some examples or propose some text?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] message digest and signature (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote:
> Item #10: You write:
>
> "
>10.  The Assertion MUST be digitally signed or have a keyed message
> digest applied by the issuer.  The authorization server MUST
> reject assertions with an invalid signature or keyed message
> digest.
> "
>
> To my knowledge SAML assertions only support digitial signatures and no
> keyed message digests.

It's built on XML Dsig which does allow for MAC. AFAIK, there's
nothing in SAML prohibiting it. But, to your point, in practice it's
always an asymmetric digital signature. I don't think that this is not
the first time we've discussed this point. Maybe omitting the mention
of keyed message digests would avoid confusion? In practice I don't
think anything would be lost for doing so.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] AuthnStatement (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote:
> Item #7+8: T I think you should combine the two items since they relate to
> the same issue, namely when to include the  element.

Okay, #7&8 can be rolled up into one item.

> There
> are two questions:
>
> Q1: Has the subject been authenticated?
>
> If 'no', then the  cannot be populated.
>
> If 'yes', then
> Q2: Has the subject requested to be anonymous?
>
> If 'no', then the  element is populated
> with the subject's identity.
>
> If 'yes', then the  MUST NOT be populated.
> (or populated with a field that indicates that the subject
>  is anonymous; I don't know SAML enough to tell what the
>  right approach here is).

#8 is about the client acting *autonomously* on behalf of the subject.
Not *anonymously*. Autonomous was a term used in earlier drafts of RFC
6749 (maybe circa -10 of draft-ietf-oauth-v2) when talking about a
client who was acting on its own without the user being present.

> Then you write:
> "
> The presenter SHOULD
> be identified in the  or similar element in the
>  element, or by other available means like
> SAML V2.0 Condition for Delegation Restriction
> [OASIS.saml-deleg-cs].
> "
>
> Who is the presenter? Is the presenter the subject?

The presenter is the thing that shows up with and presents the
assertion to the AS. It's a term used in the SAML specs. In this case
the presenter is the client. Maybe it's better to just say client here
and not use the term presenter?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] issuer (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote:
> Section 3:
>
> Item #1: You wrote: "Issuer
> values SHOULD be compared using the Simple String Comparison
> method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
> otherwise specified by the application."
>
> I would put a MUST here. You can also use the text I proposed for
> draft-ietf-oauth-jwt-bearer-06, which is text I copied from the TLS
> specification.
>
> Also the comment regarding the comparison operation I made in
> draft-ietf-oauth-jwt-bearer-06 is applicable here.

Likewise my comments and response to your comments on
draft-ietf-oauth-jwt-bearer-06 are applicable here [1].

But I'm not sure which text you are referring to from the TLS
specification? Maybe I overlooked something.

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg12249.html
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Confirmation (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote:
> Item #5: You write:
>
> "
> The  element MUST contain at least one
>  element that allows the authorization
> server to confirm it as a Bearer Assertion.
> "
>
> What do you mean that the AS confirms that it is a bearer assertion?

Confirmation is a term from SAML which is honestly not well understood
by many people (myself included) but I'm trying to be consistent with
that in how I use it here. But it's not necessary and #5 is just
stating how the  element needs to look. Perhaps
rewording it to just not use the confirm language would be better?

> I think
> what you rather want to say is that the AS indicates that it is a bearer
> assertion.

No, it's just language around what needs to be validated in the
 element of the assertion because it is a bearer
assertion.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Subject (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote:
>
> Item #3: As in the draft-ietf-oauth-jwt-bearer-06 this part is extremely
> fluffy, except for the case where it talks about the client-id. What exactly
> do I put into the field in the case of an authorization grant?

Similar to sub in the JWT draft [1], the fluff is intended to allow
for cases where the subject alone can't or shouldn't directly identify
someone. I'm open to changes that would help clarify usage (and I
think that warrants a mention in Interoperability Considerations) but
any such text needs to be reflective of reality too.

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17)

[Brian Campbell]

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
 wrote
> Item #2: You wrote:
>
> "
> Section 2.5.1.4 of Assertions and Protocols for the OASIS
> Security Assertion Markup Language [OASIS.saml-core-2.0-os]
> defines the  and  elements and,
> in addition to the URI references discussed there, the token
> endpoint URL of the authorization server MAY be used as a URI
> that identifies the authorization server as an intended
> audience.  Assertions that do not identify the Authorization
> Server as an intended audience MUST be rejected.
> "
>
> The 'MAY' is extremely weak here. If you make it a MUST that there has to be
> the endpoint URL of the authorization server in there then that would
> provide so much more interoperability. As a reader I wouldn't know what
> other options I have and systems that provision necessary databases / tables
> to ensure that the comparison takes place will also struggle.

The "MAY" is intended to be weak and is only a suggestion for
deployments which don't already have a suitable identifier (like a
SAML 2 entity ID) for an audience value.

I understand that you'd like this to be tighter but the suggestion is
not viable and it wouldn't provide the perceived interoperability
panacea anyway. Some information needs to be agreed upon for this to
work. How is out of scope here. The audience is one such value. Even
if mandating one specific thing for audience was feasible, it wouldn't
add to interoperability because there is other information that has to
be agreed on anyway.


> Then, there is again this SHOULD regarding the comparison operation, see
> "
>  Audience
> values SHOULD be compared using the Simple String Comparison
> method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
> otherwise specified by the application.
> "
>
> I would replace it with a MUST, as I argued in
> draft-ietf-oauth-jwt-bearer-06.

As I said there [1], I think I'm okay with that but would like to hear
from others in the WG.

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Interoperability Considerations (was draft-ietf-oauth-jwt-bearer-06)

[Brian Campbell]

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
 wrote:
>
> Section 5 about "Interoperability Considerations" says:
>
> "
> Specific items that require agreement are as
>follows: values for the issuer and audience identifiers, the location
>of the token endpoint, and the key used to apply and verify the
>digital signature or keyed message digest over the JWT.
> "
>
> I believe that this list is not correct.

The list could probably be expanded to include a mention of how
subject is to be identified (related to discussion about subject [1])
as well as requirements the AS may place on upper limits of token
expiration and/or de-duping.

> What is needed is:
>
>  * At the authorization server there needs to be a whitelist of trusted
> issuers. For a succesful protocol run the JWT needs to be created by an
> issuer who is in the whitelist.
>
>  * Along with the entry in the whitelist of trusted issuers needs to be a
> key.

That's one implementation approach. But not the only one. The intent
of this section is to note the information which needs to be
exchanged/agreed upon in order for the wire protocol to work. That's
all. Implementation particulars shouldn't be here.

> There is no new endpoint URL defined by this document. As such, I wouldn't
> mention those.

No but there's been a request, which makes sense, to explicitly state
the items which need to be known, typically via service documentation,
in order to achieve interoperability. The token endpoint is one of
those items and OAuth provides no means of discovering it or
publishing it. So I feel it's very appropriate to mention it here.
And, by way of example, if you look at service documentation for
existing deployments, you'll see that it is included.

> I also do not think that the audience identifier needs to be agreed if you
> define it as the token endpoint URL of the authorization server (as I
> suggested above).

As I said in the previous mail on audience [2] and have been
arguing/explaining for a long time now, that suggestion is not viable
or realistic. And (as I mention above) the token endpoint URL *still*
needs to be communicated somehow. Documenting the expected value for
audience is just one more piece of information in a set of info that
has to be exchanged anyway.


[1] sub http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html
[2] aud http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06)

[Brian Campbell]

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
 wrote:
> You write:
>
> "
>  3.   The JWT MUST contain an "aud" (audience) claim containing a
> value that identifies the authorization server as an intended
> audience.  The token endpoint URL of the authorization server
> MAY be used as a value for an "aud" element to identify the
> authorization server as an intended audience of the JWT.  JWTs
> that do not identify the authorization server as an intended
> audience MUST be rejected
> "
>
> If the endpoint URL of the AS is not used then what else? Wouldn't it be
> useful to say "The token endpoint URL of the authorization server
> MUST be used as a value for an "aud" element to identify the
> authorization server as an intended audience of the JWT."?

This and the other assertion documents offer the token endpoint URL as
one way to identify the AS for deployments which lack some other means
of doing so. However, these assertion profiles are little slices of
functionality that augment existing deployments of OAuth, often in
conjunction with other 'federated' technologies for which there will
be an existing and agreed upon identifier that the issuer is known by.
This is not just academic - it's how these systems and deployment
already work. It's inappropriate and unrealistic for this document (or
the other assertion docs) to preclude common and useful deployment
practices.

> Then, I have a suggestion for re-phrasing this sentence from :
> "
> Audience values SHOULD be compared
> using the Simple String Comparison method defined in Section
> 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
> application.
> "
> to:
>
> "
> In the absence of an application profile standard specifying
> otherwise, a compliant JWT Bearer application MUST compare the audience
> values using the Simple String Comparison method defined in Section
> 6.2.1 of RFC 3986 [RFC3986].
> "

I think I'm okay with that re-phrasing. Do others (my co-authors
especially) agree? Or object?

>
> The same can actually be applied to the issuer claim as well.

As I said in the previous mail about issuer, I'd like to get rid of
the comparison text. However, if such text stays, I'll work to make it
consistent throughout.

> Given that the JWT had been updated to align it with the JOSE work I suspect
> that this document also requires an update.

You may well be correct. But despite following the JOSE and JWT work,
I'm not sure I know what update(s) would be required. Can you
elaborate?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] subject (was draft-ietf-oauth-jwt-bearer-06)

[Brian Campbell]

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
 wrote:
> You write:
> "
>2.   The JWT MUST contain a "sub" (subject) claim identifying the
> subject of the transaction.  The subject MAY identify the
> resource owner for whom the access token is being requested.
>
> A.  When using a JWT as an authorization grant, the subject
> SHOULD identify an authorized accessor for whom the access
> token is being requested (typically the resource owner, or
> an authorized delegate).
>
> B.  For client authentication, the subject MUST be the
> "client_id" of the OAuth client.
> "
>
> Should this rather read:
>
> "
>2.   The JWT MUST contain a "sub" (subject) claim identifing the
> principal that is the subject of the JWT. Two cases need to
> be differentiated:
>
> A.  For the authorization grant, the subject
> SHOULD identify an authorized accessor for whom the access
> token is being requested (typically the resource owner, or
> an authorized delegate).
>
> B.  For client authentication, the subject MUST be the
> "client_id" of the OAuth client.
> "

Agreed that reads better.

> Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A
> is so fuzzy that it actually doesn't allow someone to create a test case to
> test whether an implementation is interoperable or not. With B the situation
> is different. Is there something else we can say for A?

The fuzziness of the text in A, I believe, comes from use cases where
the principal wouldn't directly be identified in the sub claim. For
example, a JWT with an anonymous subject and a claim stating they are
a member of a particular group might be sufficient to grant access to
some types of resources (this is discussed in
http://tools.ietf.org/html/draft-ietf-oauth-assertions-12#section-6.3.1).
It is also not uncommon, in this federated scenarios, for additional
claims/attributes to be needed along with the subject in order to
uniquely identify the principle as known to the AS.

Is there a way to rephrase the text for A which would be more helpful
but not preclude such use cases?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] issuer (was draft-ietf-oauth-jwt-bearer-06)

[Brian Campbell]

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
 wrote:
>
> Section 3:
>
> You write:
> "
>1.   The JWT MUST contain an "iss" (issuer) claim that contains a
> unique identifier for the entity that issued the JWT.  Issuer
> values SHOULD be compared using the Simple String Comparison
> method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
> otherwise specified by the application.
> "
>
> What is not stated here is what are the two values that are compared against
> each other. One value is the issuer claim from the JWT and the other value
> is the, I guess, an entry from a whitelist of trusted issuers.

Yes, typically the issuer value is used to lookup policy or
configuration data in order to process the transaction. But that is an
implementation choice and certainly not the only way it could be done.

I've always thought that talking about comparing issuer values is
somewhat misleading. Can that second sentence be omitted? Or is there
a better way to convey what is intended here? Which is, I think, that
even though issuer may be a URI, it should simply be treated as a case
sensitive string?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-06

[Brian Campbell]

Thanks for the review and feedback Hannes.

There are a number of different items here and I think it'll be more
productive to discuss them individually, so I'll partition this into a
different threads for each general topic. I plan to do the same thing
for your review of draft-ietf-oauth-saml2-bearer-17 from
http://www.ietf.org/mail-archive/web/oauth/current/msg12230.html

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
 wrote:
> Hi Mike, Hi all,
>
> I read through draft-ietf-oauth-jwt-bearer-06 in an attempt to find out
> whether I would be able to produce an interoperable implementation from this
> document.
>
> A few minor things came to my mind:
>
> Section 3:
>
> You write:
> "
>1.   The JWT MUST contain an "iss" (issuer) claim that contains a
> unique identifier for the entity that issued the JWT.  Issuer
> values SHOULD be compared using the Simple String Comparison
> method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
> otherwise specified by the application.
> "
>
> What is not stated here is what are the two values that are compared against
> each other. One value is the issuer claim from the JWT and the other value
> is the, I guess, an entry from a whitelist of trusted issuers.
>
>
>
> You write:
> "
>2.   The JWT MUST contain a "sub" (subject) claim identifying the
> subject of the transaction.  The subject MAY identify the
> resource owner for whom the access token is being requested.
>
> A.  When using a JWT as an authorization grant, the subject
> SHOULD identify an authorized accessor for whom the access
> token is being requested (typically the resource owner, or
> an authorized delegate).
>
> B.  For client authentication, the subject MUST be the
> "client_id" of the OAuth client.
> "
>
> Should this rather read:
>
> "
>2.   The JWT MUST contain a "sub" (subject) claim identifing the
> principal that is the subject of the JWT. Two cases need to
> be differentiated:
>
> A.  For the authorization grant, the subject
> SHOULD identify an authorized accessor for whom the access
> token is being requested (typically the resource owner, or
> an authorized delegate).
>
> B.  For client authentication, the subject MUST be the
> "client_id" of the OAuth client.
> "
>
> Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A
> is so fuzzy that it actually doesn't allow someone to create a test case to
> test whether an implementation is interoperable or not. With B the situation
> is different. Is there something else we can say for A?
>
> You write:
>
> "
>  3.   The JWT MUST contain an "aud" (audience) claim containing a
> value that identifies the authorization server as an intended
> audience.  The token endpoint URL of the authorization server
> MAY be used as a value for an "aud" element to identify the
> authorization server as an intended audience of the JWT.  JWTs
> that do not identify the authorization server as an intended
> audience MUST be rejected.  Audience values SHOULD be compared
> using the Simple String Comparison method defined in Section
> 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
> application.
> "
>
> If the endpoint URL of the AS is not used then what else? Wouldn't it be
> useful to say "The token endpoint URL of the authorization server
> MUST be used as a value for an "aud" element to identify the
> authorization server as an intended audience of the JWT."?
>
> Then, I have a suggestion for re-phrasing this sentence from :
> "
> Audience values SHOULD be compared
> using the Simple String Comparison method defined in Section
> 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
> application.
> "
> to:
>
> "
> In the absence of an application profile standard specifying
> otherwise, a compliant JWT Bearer application MUST compare the audience
> values using the Simple String Comparison method defined in Section
> 6.2.1 of RFC 3986 [RFC3986].
> "
>
> The same can actually be applied to the issuer claim as well.
> Given that the JWT had been updated to align it with the JOSE work I suspect
> that this document also requires an update.
>
>
> Section 5 about "Interoperability Considerations" says:
>
> "
> Specific items that require agreement are as
>follows: values for the issuer and audience identifiers, the location
>of the token endpoint, and the key used to apply and verify the
>digital signature or keyed message digest over the JWT.
> "
>
> I believe that this list is not correct.
>
> What is needed is:
>
>  * At the authorization server there needs to be a whitelist of trusted
> issuers. For a succesful protocol run the JWT needs to be created by an
> issuer who is 

[OAUTH-WG] [Technical Errata Reported] RFC6749 (3780)

[RFC Errata System]

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3780

--
Type: Technical
Reported by: Torsten Lodderstedt 

Section: 3.2.1

Original Text
-
A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.

Corrected Text
--
A public client MAY use the "client_id" request parameter to identify 
itself when sending requests to the token endpoint.

Notes
-
The current text may mislead confidential clients to sent their client_id in 
the request body in addition to their client_id and client_secret in the BASIC 
authz header. This leads to unnecessary duplication and ambiguities. 

There has been consensus on the list that the intention of this sentence was to 
advise _public_ clients to identity themselves towards the token endpoint in 
order to mitigate substitution attacks and allow for logging. Confidential 
clients need to authenticate anyway, this sentence should be narrowed down to 
public clients only. 

see http://www.ietf.org/mail-archive/web/oauth/current/msg12005.html

This issue was discovered in the course of the OpenID Connect Interop testings.

Instructions:
-
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth