Re: [OAUTH-WG] JWT grant_type and client_id

[Brian Campbell]

Just trying to close the loop on this thread (six weeks later, sorry). New
drafts were published last month that (hopefully) have more clear text
about the treatment of client_id. And it's been removed from examples where
it's optional.

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


On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin wrote:

> Hi,
>
> Just one remark, the example in [1] shows "client_id"; IMHO it makes sense
> to clarify than in this context (where the assertion is used as a grant),
> it is optional as per:
>
> http://tools.ietf.org/html/**rfc6749#section-3.2.1
>
> "A client MAY use the "client_id" request parameter to identify itself
>  when sending requests to the token endpoint"
>
> and otherwise
>
> http://tools.ietf.org/html/**rfc6749#section-2.3
>
> dictates how the client authentication is done.
>
> By the way, my reading of the main spec's section 2.3 tells me that the
> only time one would use only "client_id" in the form payload is when the
> client secret is empty or perhaps the client is not in the possession of
> the secret.
>
> Does it make sense to completely drop a "client_id" parameter in the
> example at [1] in the assertion draft and use an example with a Basic
> authentication instead ?
>
> Thanks, Sergey
>
>
> On 15/03/13 22:12, Brian Campbell wrote:
>
>> So currently the base assertion document defines scope as an HTTP
>> parameter on the access token request message when using an assertion as
>> a grant[1].  And that applies to both the SAML and JWT grants (perhaps
>> that needs to be more clear?). Also RFC 6749 defines the scope parameter
>> for the client credentials access token request[2], which similarly
>> applies to both SAML and JWT in the case of assertion client
>> authentication using the "client_credentials" grant type.
>>
>> [1] http://tools.ietf.org/html/**draft-ietf-oauth-assertions-**
>> 10#section-4.1
>> [2] 
>> http://tools.ietf.org/html/**rfc6749#section-4.4.1
>>
>>
>> On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022
>> 
>> >
>> wrote:
>>
>> Right ... thinking about this further I think the answer is "all of
>> the above."  If the JWT is a grant type then as you say it needs a
>> scope param and optionally a client_id param.  I argued for the
>> client_id param earlier since it could assist with HOK scenarios
>> once those further develop.
>>
>> But when the JWT is used as an AT then it will definitely require
>> the scope as a claim.
>>
>> So I change my argument to "both" :)
>>
>> adam
>>
>> -Original Message-
>> From: oauth-boun...@ietf.org 
>> [mailto:oauth-boun...@ietf.org ] On
>> Behalf Of Sergey Beryozkin
>> Sent: Friday, March 15, 2013 4:31 PM
>> To: oauth@ietf.org 
>> Subject: Re: [OAUTH-WG] JWT grant_type and client_id
>>
>> Hi
>> On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
>>  > Hi John,
>>  >
>>  > I would like to argue that the scope should be a parameter in the
>> access
>>  > token request message, the same as it is for the RO creds grant and
>>  > client creds grant type. This would keep it consistent with the
>> core
>>  > OAuth grant types that talk directly to the token endpoint.
>>  >
>> Assuming the assertion is acting as a grant, then it is indeed an
>> access
>> token request message, so IMHO it makes sense to get an outbound scope
>> parameter optionally supported which I guess will imply that the
>> client
>> id will also have to accompany it...
>>
>> Cheers, Sergey
>>
>>  > Thoughts?
>>  >
>>  > adam
>>  >
>>  > *From:*John Bradley [mailto:ve7...@ve7jtb.com
>> ]
>>  > *Sent:* Friday, March 15, 2013 12:10 PM
>>  > *To:* Lewis Adam-CAL022
>>  > *Cc:* Brian Campbell; "WG > >"@il06**exr02.mot.com<
>> http://il06exr02.mot.com>
>>   > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>>  >
>>  > The spec is a touch vague on that. I think the scopes should be
>> in the
>>  > assertion and the client can use the scopes outside the assertion
>> to
>>  > down-scope.
>>  >
>>  > Having a standard claim in JWT and SAML for passing scopes is
>> probably
>>  > useful as part of a profile.
>>  >
>>  > John B.
>>  >
>>  > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022
>>  > 
>> 
>> > >
>>  > 
>> >
>> 
>> >>
>> wrote:
>>  >
>>

Re: [OAUTH-WG] JWT grant_type and client_id

[Phil Hunt]

I find the text confusing regarding client auth.
>> "A client MAY use the "client_id" request parameter to identify itself
>>  when sending requests to the token endpoint"

 It seems to suggest client auth is optional due to the MAY when in fact it is 
just referring to the client_id identifier which is not authn. I fear many have 
missed this subtle distinction.  Or did you really intend optionality for 
assertions?

Phil

On 2013-05-01, at 5:35, Brian Campbell  wrote:

> Just trying to close the loop on this thread (six weeks later, sorry). New 
> drafts were published last month that (hopefully) have more clear text about 
> the treatment of client_id. And it's been removed from examples where it's 
> optional.
> 
> http://www.ietf.org/mail-archive/web/oauth/current/msg11213.html
> 
> 
> On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin  
> wrote:
>> Hi,
>> 
>> Just one remark, the example in [1] shows "client_id"; IMHO it makes sense 
>> to clarify than in this context (where the assertion is used as a grant), it 
>> is optional as per:
>> 
>> http://tools.ietf.org/html/rfc6749#section-3.2.1
>> 
>> "A client MAY use the "client_id" request parameter to identify itself
>>  when sending requests to the token endpoint"
>> 
>> and otherwise
>> 
>> http://tools.ietf.org/html/rfc6749#section-2.3
>> 
>> dictates how the client authentication is done.
>> 
>> By the way, my reading of the main spec's section 2.3 tells me that the only 
>> time one would use only "client_id" in the form payload is when the client 
>> secret is empty or perhaps the client is not in the possession of the secret.
>> 
>> Does it make sense to completely drop a "client_id" parameter in the example 
>> at [1] in the assertion draft and use an example with a Basic authentication 
>> instead ?
>> 
>> Thanks, Sergey
>> 
>> 
>> On 15/03/13 22:12, Brian Campbell wrote:
>>> So currently the base assertion document defines scope as an HTTP
>>> parameter on the access token request message when using an assertion as
>>> a grant[1].  And that applies to both the SAML and JWT grants (perhaps
>>> that needs to be more clear?). Also RFC 6749 defines the scope parameter
>>> for the client credentials access token request[2], which similarly
>>> applies to both SAML and JWT in the case of assertion client
>>> authentication using the "client_credentials" grant type.
>>> 
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1
>>> [2] http://tools.ietf.org/html/rfc6749#section-4.4.1
>>> 
>>> 
>>> On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022
>>> >> > wrote:
>>> 
>>> Right ... thinking about this further I think the answer is "all of
>>> the above."  If the JWT is a grant type then as you say it needs a
>>> scope param and optionally a client_id param.  I argued for the
>>> client_id param earlier since it could assist with HOK scenarios
>>> once those further develop.
>>> 
>>> But when the JWT is used as an AT then it will definitely require
>>> the scope as a claim.
>>> 
>>> So I change my argument to "both" :)
>>> 
>>> adam
>>> 
>>> -Original Message-
>>> From: oauth-boun...@ietf.org 
>>> [mailto:oauth-boun...@ietf.org ] On
>>> Behalf Of Sergey Beryozkin
>>> Sent: Friday, March 15, 2013 4:31 PM
>>> To: oauth@ietf.org 
>>> Subject: Re: [OAUTH-WG] JWT grant_type and client_id
>>> 
>>> Hi
>>> On 15/03/13 20:40, Lewis Adam-CAL022 wrote:
>>>  > Hi John,
>>>  >
>>>  > I would like to argue that the scope should be a parameter in the
>>> access
>>>  > token request message, the same as it is for the RO creds grant and
>>>  > client creds grant type. This would keep it consistent with the core
>>>  > OAuth grant types that talk directly to the token endpoint.
>>>  >
>>> Assuming the assertion is acting as a grant, then it is indeed an access
>>> token request message, so IMHO it makes sense to get an outbound scope
>>> parameter optionally supported which I guess will imply that the client
>>> id will also have to accompany it...
>>> 
>>> Cheers, Sergey
>>> 
>>>  > Thoughts?
>>>  >
>>>  > adam
>>>  >
>>>  > *From:*John Bradley [mailto:ve7...@ve7jtb.com
>>> ]
>>>  > *Sent:* Friday, March 15, 2013 12:10 PM
>>>  > *To:* Lewis Adam-CAL022
>>>  > *Cc:* Brian Campbell; "WG >> >"@il06exr02.mot.com 
>>>  > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id
>>>  >
>>>  > The spec is a touch vague on that. I think the scopes should be
>>> in the
>>>  > assertion and the client can use the scopes outside the assertion to
>>>  > down-scope.
>>>  >
>>>  > Having a standard claim in JWT and SAML for passing scopes is
>>> probably
>>>

[OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-04.txt

[Justin Richer]

I just rev'd the OAuth Introspection draft to cover some of the issues 
outstanding, such as alignment with JWT claim types, fields for token 
types (copied from revocation), and TLS restrictions.


 -- Justin


 Original Message 
Subject: 	New Version Notification for 
draft-richer-oauth-introspection-04.txt

Date:   Wed, 1 May 2013 13:22:21 -0700
From:   
To: Justin Richer 



A new version of I-D, draft-richer-oauth-introspection-04.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:draft-richer-oauth-introspection
Revision:04
Title:   OAuth Token Introspection
Creation date:   2013-05-01
Group:   Individual Submission
Number of pages: 6
URL: 
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-04.txt
Status:  
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-04

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


  



The IETF Secretariat



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

[OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

[Dick Hardt]

"iss" and "aud" would be optional parameters in a JWE. These parameters are in 
the payload, but since it is encrypted, the payload must be decrypted before 
they can be read. Some times knowing these parameters is required to be able to 
decrypt the payload …

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify and 
decrypt tokens from them. 

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App to do 
something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to know who 
sent the token, is to look at the KID as the "iss" claim is encrypted. If the 
"kid" values are GUIDs, then Alice can just look up the "kid" and retrieve the 
associated symmetric key, and then decrypt and verify the token and THEN see 
who sent it. If there is a collision in KID values (Bon and Charlie gave the 
same KID for different keys), then Alice will not know which symmetric key to 
use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and 
symmetric key to Gwen. 

Ellen and Gwen trust each other and know how to talk to each other. Gwen does 
not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)

Gwen now has a token that Ellen can decrypt and verify, but has no method for 
knowing that Ellen can do that. The "aud" property would allow Gwen to give the 
token to Ellen to decrypt and verify.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

[Mike Jones]

Thanks for writing this, Dick.  I think I understand your requirements and why 
they exist.

One question you didn't answer that will come up is whether these fields must 
also be present in the JWT claims set if they're present in the JWE header.  
The logical answer to me seems to be something like "All claims MUST be present 
in the JWT Claims Set; specified claims MAY also be duplicated in the JWE 
header, and if present there, must have exactly the same values as in the JWT 
Claims Set."

Is that the way that you imagined this working?

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dick 
Hardt
Sent: Wednesday, May 01, 2013 2:12 PM
To: O Auth WG
Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names 
in JWE

"iss" and "aud" would be optional parameters in a JWE. These parameters are in 
the payload, but since it is encrypted, the payload must be decrypted before 
they can be read. Some times knowing these parameters is required to be able to 
decrypt the payload ...

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify and 
decrypt tokens from them. 

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App to do 
something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to know who 
sent the token, is to look at the KID as the "iss" claim is encrypted. If the 
"kid" values are GUIDs, then Alice can just look up the "kid" and retrieve the 
associated symmetric key, and then decrypt and verify the token and THEN see 
who sent it. If there is a collision in KID values (Bon and Charlie gave the 
same KID for different keys), then Alice will not know which symmetric key to 
use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and 
symmetric key to Gwen. 

Ellen and Gwen trust each other and know how to talk to each other. Gwen does 
not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)

Gwen now has a token that Ellen can decrypt and verify, but has no method for 
knowing that Ellen can do that. The "aud" property would allow Gwen to give the 
token to Ellen to decrypt and verify.
___
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] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

[Dick Hardt]

Hi Mike

That answer makes the most sense to me as those values are often required when 
processing a payload as well, and they should be consistent. I'd be interested 
to hear any other opinions though!

-- Dick

On May 1, 2013, at 3:48 PM, Mike Jones  wrote:

> Thanks for writing this, Dick.  I think I understand your requirements and 
> why they exist.
> 
> One question you didn't answer that will come up is whether these fields must 
> also be present in the JWT claims set if they're present in the JWE header.  
> The logical answer to me seems to be something like "All claims MUST be 
> present in the JWT Claims Set; specified claims MAY also be duplicated in the 
> JWE header, and if present there, must have exactly the same values as in the 
> JWT Claims Set."
> 
> Is that the way that you imagined this working?
> 
>   -- Mike
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Dick Hardt
> Sent: Wednesday, May 01, 2013 2:12 PM
> To: O Auth WG
> Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter 
> Names in JWE
> 
> "iss" and "aud" would be optional parameters in a JWE. These parameters are 
> in the payload, but since it is encrypted, the payload must be decrypted 
> before they can be read. Some times knowing these parameters is required to 
> be able to decrypt the payload ...
> 
> These would be additions to 9.3.1 in the JWT specification.
> 
> Why "iss" is needed:
> 
> Bob and Charlie each gave Alice a KID and a symmetric key to use to verify 
> and decrypt tokens from them. 
> 
> The App and Alice share keys so Alice knows it is the App.
> 
> The User authorizes Bob to give the App a token (which authorizes the App to 
> do something)
> 
> The App gives the token to Alice.
> 
> Since Alice indirectly received the token,  the only way for Alice to know 
> who sent the token, is to look at the KID as the "iss" claim is encrypted. If 
> the "kid" values are GUIDs, then Alice can just look up the "kid" and 
> retrieve the associated symmetric key, and then decrypt and verify the token 
> and THEN see who sent it. If there is a collision in KID values (Bon and 
> Charlie gave the same KID for different keys), then Alice will not know which 
> symmetric key to use.
> 
> Why "aud" is needed:
> 
> Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and 
> symmetric key to Gwen. 
> 
> Ellen and Gwen trust each other and know how to talk to each other. Gwen does 
> not know Dave. Ellen does not know Frank
> 
> The App and Gwen share keys so Gwen knows it is the App.
> 
> The User authorizes Dave to give the App a token
> 
> Dave gives the token to Gwen (Dave does not have a relationship with Ellen)
> 
> Gwen now has a token that Ellen can decrypt and verify, but has no method for 
> knowing that Ellen can do that. The "aud" property would allow Gwen to give 
> the token to Ellen to decrypt and verify.
> ___
> 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