date:20141111

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

2014-11-11 Thread Mike Jones

Thanks!

From: Richard Barnes
Sent: ‎11/‎11/‎2014 3:30 PM
To: Mike Jones
Cc: Brian Campbell; John 
Bradley; 
draft-ietf-oauth-asserti...@tools.ietf.org;
 Pete Resnick; oauth; 
The IESG; 
oauth-cha...@tools.ietf.org
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Looks good to me, thanks.  I cleared.
--Richard

On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Richard, yours are the only discusses on draft-ietf-oauth-assertions, 
draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re all 
about the audience requirement. Brian added text addressing this in the last 
paragraph of 
https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.  Are you 
willing to clear these DISCUSSes on this basis?

If not, can we try to talk before the OAuth meeting tomorrow morning?  I’ll be 
leading the assertions drafts discussions tomorrow since Brian won’t be able to 
attend.

Thanks,
-- Mike

From: Brian Campbell 
[mailto:bcampb...@pingidentity.com]
Sent: Friday, October 17, 2014 8:23 AM
To: Richard Barnes
Cc: John Bradley; 
draft-ietf-oauth-asserti...@tools.ietf.org;
 Pete Resnick; oauth; The IESG; 
oauth-cha...@tools.ietf.org
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

That text works for me, Richard. Thanks.
I will go with Richard's text in the next draft, unless I hear objections.

FWIW, the mention of HoK was a result of a review and suggestions from Hannes 
some time ago.

http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt

It could be removed, to your point, but I think your proposed text is very 
clear about the scope and might help prevent confusion.

On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes 
mailto:r...@ipv.sx>> wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I think this part of sec 3 of assertions states that:

 The protocol parameters and processing rules defined in this document

   are intended to support a client presenting a bearer assertion to an

   authorization server.  The use of holder-of-key assertions are not

   precluded by this document, but additional protocol details would

   need to be specified.

As part of defining the additional protocol details for holder-of-key/PoP we 
can relax the must for audience in the profile that defines how to use those 
assertion types.

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials here?  
The entire remainder of the spec is written as if they didn't exist.  And as 
the text above notes, you can't actually use them with this specification.
If we're going to keep the mention, could we augment the text above to make it 
clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""
--Richard

John B.

On Oct 17, 2014, at 2:25 PM, Pete Resnick 
mailto:presn...@qti.qualcomm.com>> wrote:

On 10/17/14 12:09 PM, Mike Jones wrote:
This is the standard mitigation for a known set of actual attacks.  We 
shouldn’t even consider making it optional.

Do you mean you shouldn't consider making it optional for HoK? Again, making it 
clear that the MUST applies only to bearer assertions, and that future 
extensions for HoK might have different requirements, is all that is being 
asked for here.

pr

--

Pete Resnick 

Qualcomm Technologies, Inc. - +1 (858)651-4478

___
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] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

2014-11-11 Thread Richard Barnes

Looks good to me, thanks.  I cleared.
--Richard

On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones 
wrote:

>  Richard, yours are the only discusses on draft-ietf-oauth-assertions,
> draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re
> all about the audience requirement. Brian added text addressing this in
> the last paragraph of
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.
> Are you willing to clear these DISCUSSes on this basis?
>
>
>
> If not, can we try to talk before the OAuth meeting tomorrow morning?
> I’ll be leading the assertions drafts discussions tomorrow since Brian
> won’t be able to attend.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Friday, October 17, 2014 8:23 AM
> *To:* Richard Barnes
> *Cc:* John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete
> Resnick; oauth; The IESG; oauth-cha...@tools.ietf.org
> *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> That text works for me, Richard. Thanks.
>
> I will go with Richard's text in the next draft, unless I hear objections.
>
>
>
> FWIW, the mention of HoK was a result of a review and suggestions from
> Hannes some time ago.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt
>
>
>
> It could be removed, to your point, but I think your proposed text is very
> clear about the scope and might help prevent confusion.
>
>
>
>
>
> On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes  wrote:
>
> On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:
>
>  I think this part of sec 3 of assertions states that:
>
>
>
>  The protocol parameters and processing rules defined in this document
>
>are intended to support a client presenting a bearer assertion to an
>
>authorization server.  The use of holder-of-key assertions are not
>
>precluded by this document, but additional protocol details would
>
>need to be specified.
>
>
>
>
>
> As part of defining the additional protocol details for holder-of-key/PoP
> we can relax the must for audience in the profile that defines how to use
> those assertion types.
>
>
>
> I think we're on a path to convergence here.
>
>
>
> Given all this, is there any point to even mentioning HoK credentials
> here?  The entire remainder of the spec is written as if they didn't
> exist.  And as the text above notes, you can't actually use them with this
> specification.
>
> If we're going to keep the mention, could we augment the text above to
> make it clearer that HoK assertions are out of scope.
>
>
> """
>
> The protocol parameters and processing rules defined in this document
> are intended to support a client presenting a bearer assertion to an
> authorization server.  They are not suitable for use with holder-of-key
> assertions.  While they could be used as a baseline for a holder-of-key
>
> assertion system, there would be a need for additional mechanisms
>
> (to support proof of possession of the secret key), and possibly changes
> to the security model (e.g., to relax the requirement for an Audience).
>
> """
>
> --Richard
>
>
>
>
>
>
> John B.
>
>
>
> On Oct 17, 2014, at 2:25 PM, Pete Resnick 
> wrote:
>
>
>
>  On 10/17/14 12:09 PM, Mike Jones wrote:
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
> Do you mean you shouldn't consider making it optional for HoK? Again,
> making it clear that the MUST applies only to bearer assertions, and that
> future extensions for HoK might have different requirements, is all that is
> being asked for here.
>
> pr
>
>  --
>
> Pete Resnick  
> 
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>
>
>
>
>
> ___
> 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] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

2014-11-11 Thread Stephen Farrell


Yeah I think that's fair (though regrettable:-). Will look at it
before the meeting.

S

On 12/11/14 00:03, Mike Jones wrote:
> Hi Stephen,
> 
> Your DISCUSS on "alg":"none" being MTI is the only one remaining on the JWT 
> draft.  Given the working group support for keeping things the way they are, 
> would you be willing to clear this DISCUSS on that basis?  The OAuth WG 
> meeting is tomorrow, so it would be good to hear your thoughts before then, 
> if possible.
> 
>   Thanks,
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Friday, October 24, 2014 8:33 PM
> To: 'Stephen Farrell'; The IESG
> Cc: oauth-cha...@tools.ietf.org; 
> draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
> draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
> 
> Hi Stephen,
> 
> I applied your privacy wording to the -30 draft.  Thanks.
> 
> About your DISCUSS on "alg":"none" being MTI, several working group members 
> have chimed in agreeing that it should continue to be MTI, and said why.  In 
> summary - unsigned security tokens representing claims are really common in 
> identity protocols; interop will be improved if this functionality is MTI.  
> Can I therefore ask you hold your nose a little bit more and clear this 
> remaining DISCUSS?
> 
>   Thanks again,
>   -- Mike
> 
> -Original Message-
> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
> Sent: Tuesday, October 21, 2014 6:17 AM
> To: Mike Jones; The IESG
> Cc: oauth-cha...@tools.ietf.org; 
> draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: 
> (with DISCUSS and COMMENT)
> 
> 
> Hi Mike,
> 
> I've one remaining discuss point and a comment. See below...
> 
> On 14/10/14 13:50, Mike Jones wrote:
>> The proposed resolutions below have been included in the -28 draft.  
>> Hopefully you'll be able to clear your DISCUSSes on that basis.
>>
>> The String Comparison Rules in Section 7.3 have been expanded to talk about 
>> when the application may need canonicalization rules.
>>
>>  Thanks again,
>>  -- Mike
>>
>>> -Original Message-
>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
>>> Sent: Monday, October 06, 2014 7:20 PM
>>> To: Stephen Farrell; The IESG
>>> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- 
>>> to...@tools.ietf.org; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
>>> draft-ietf-oauth-json-
>>> web-token-27: (with DISCUSS and COMMENT)
>>>
>>> Thanks for tracking all of this Stephen.  Responses inline below...
>>>
 -Original Message-
 From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
 Sent: Monday, October 06, 2014 2:43 PM
 To: Mike Jones; The IESG
 Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- 
 to...@tools.ietf.org; oauth@ietf.org
 Subject: Re: Stephen Farrell's Discuss on 
 draft-ietf-oauth-json-web-token-27:
 (with DISCUSS and COMMENT)


 Hi Mike,

 On 06/10/14 08:54, Mike Jones wrote:
> Thanks for your review, Stephen.  I've added the working group to 
> the thread so they're aware of your comments.
>
>> -Original Message- From: Stephen Farrell 
>> [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 
>> 2014
>> 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org;
>> draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen 
>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with 
>> DISCUSS and COMMENT)
>>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-oauth-json-web-token-27: Discuss
>>
>> When responding, please keep the subject line intact and reply to 
>> all email addresses included in the To and CC lines. (Feel free to 
>> cut this introductory paragraph, however.)
>>
>>
>> Please refer to
>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more 
>> information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found
>> here:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
>>
>>
>>
>> --
>> -
>> --
>> -
>>
>>
 DISCUSS:
>> --
>> -
>> --
>> -
>>
>>
>>
>>
 (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I 
 raised wrt DNS
>> names for another JOSE spec - do you need to say those SHOULD be 
>

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

2014-11-11 Thread Mike Jones

Richard, yours are the only discusses on draft-ietf-oauth-assertions, 
draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re all 
about the audience requirement. Brian added text addressing this in the last 
paragraph of 
https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.  Are you 
willing to clear these DISCUSSes on this basis?

If not, can we try to talk before the OAuth meeting tomorrow morning?  I’ll be 
leading the assertions drafts discussions tomorrow since Brian won’t be able to 
attend.

Thanks,
-- Mike

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, October 17, 2014 8:23 AM
To: Richard Barnes
Cc: John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete Resnick; 
oauth; The IESG; oauth-cha...@tools.ietf.org
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

That text works for me, Richard. Thanks.
I will go with Richard's text in the next draft, unless I hear objections.

FWIW, the mention of HoK was a result of a review and suggestions from Hannes 
some time ago.

http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt

It could be removed, to your point, but I think your proposed text is very 
clear about the scope and might help prevent confusion.


On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes 
mailto:r...@ipv.sx>> wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I think this part of sec 3 of assertions states that:


 The protocol parameters and processing rules defined in this document

   are intended to support a client presenting a bearer assertion to an

   authorization server.  The use of holder-of-key assertions are not

   precluded by this document, but additional protocol details would

   need to be specified.


As part of defining the additional protocol details for holder-of-key/PoP we 
can relax the must for audience in the profile that defines how to use those 
assertion types.

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials here?  
The entire remainder of the spec is written as if they didn't exist.  And as 
the text above notes, you can't actually use them with this specification.
If we're going to keep the mention, could we augment the text above to make it 
clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""
--Richard



John B.

On Oct 17, 2014, at 2:25 PM, Pete Resnick 
mailto:presn...@qti.qualcomm.com>> wrote:


On 10/17/14 12:09 PM, Mike Jones wrote:
This is the standard mitigation for a known set of actual attacks.  We 
shouldn’t even consider making it optional.

Do you mean you shouldn't consider making it optional for HoK? Again, making it 
clear that the MUST applies only to bearer assertions, and that future 
extensions for HoK might have different requirements, is all that is being 
asked for here.

pr


--

Pete Resnick 


Qualcomm Technologies, Inc. - +1 (858)651-4478



___
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] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

2014-11-11 Thread Mike Jones

Hi Stephen,

Your DISCUSS on "alg":"none" being MTI is the only one remaining on the JWT 
draft.  Given the working group support for keeping things the way they are, 
would you be willing to clear this DISCUSS on that basis?  The OAuth WG meeting 
is tomorrow, so it would be good to hear your thoughts before then, if possible.

Thanks,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, October 24, 2014 8:33 PM
To: 'Stephen Farrell'; The IESG
Cc: oauth-cha...@tools.ietf.org; 
draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Hi Stephen,

I applied your privacy wording to the -30 draft.  Thanks.

About your DISCUSS on "alg":"none" being MTI, several working group members 
have chimed in agreeing that it should continue to be MTI, and said why.  In 
summary - unsigned security tokens representing claims are really common in 
identity protocols; interop will be improved if this functionality is MTI.  Can 
I therefore ask you hold your nose a little bit more and clear this remaining 
DISCUSS?

Thanks again,
-- Mike

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Tuesday, October 21, 2014 6:17 AM
To: Mike Jones; The IESG
Cc: oauth-cha...@tools.ietf.org; 
draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org
Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: 
(with DISCUSS and COMMENT)


Hi Mike,

I've one remaining discuss point and a comment. See below...

On 14/10/14 13:50, Mike Jones wrote:
> The proposed resolutions below have been included in the -28 draft.  
> Hopefully you'll be able to clear your DISCUSSes on that basis.
> 
> The String Comparison Rules in Section 7.3 have been expanded to talk about 
> when the application may need canonicalization rules.
> 
>   Thanks again,
>   -- Mike
> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
>> Sent: Monday, October 06, 2014 7:20 PM
>> To: Stephen Farrell; The IESG
>> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- 
>> to...@tools.ietf.org; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
>> draft-ietf-oauth-json-
>> web-token-27: (with DISCUSS and COMMENT)
>>
>> Thanks for tracking all of this Stephen.  Responses inline below...
>>
>>> -Original Message-
>>> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
>>> Sent: Monday, October 06, 2014 2:43 PM
>>> To: Mike Jones; The IESG
>>> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- 
>>> to...@tools.ietf.org; oauth@ietf.org
>>> Subject: Re: Stephen Farrell's Discuss on 
>>> draft-ietf-oauth-json-web-token-27:
>>> (with DISCUSS and COMMENT)
>>>
>>>
>>> Hi Mike,
>>>
>>> On 06/10/14 08:54, Mike Jones wrote:
 Thanks for your review, Stephen.  I've added the working group to 
 the thread so they're aware of your comments.

> -Original Message- From: Stephen Farrell 
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 
> 2014
> 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org;
> draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen 
> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with 
> DISCUSS and COMMENT)
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-json-web-token-27: Discuss
>
> When responding, please keep the subject line intact and reply to 
> all email addresses included in the To and CC lines. (Feel free to 
> cut this introductory paragraph, however.)
>
>
> Please refer to
> http://www.ietf.org/iesg/statement/discuss-criteria.html for more 
> information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found
> here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
>
>
>
> --
> -
> --
> -
>
>
>>> DISCUSS:
> --
> -
> --
> -
>
>
>
>
>>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I 
>>> raised wrt DNS
> names for another JOSE spec - do you need to say those SHOULD be 
> [upper|lower]cased when used in these?

 I believe that somewhere we should say that if case-insensitive 
 values, such as DNS names, are used when constructing "kid" values, 
 that the application doing so needs to define a convention on the 
 canonical case to use for the

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread Sergey Beryozkin


Hi John

Sorry for being noisy. I'd like to clarify.
I was not thinking of the application getting a JWS, I was rather 
thinking of doing something similar to GZIP really, where on the wire we 
see a gzipped payload but the application gets the data it understands. 
One filter would validate the 'basic' signature of the headers/URI, the 
other - of the payload while unwrapping JWS.


What I do like about JWS/JWE is that it is neatly structured such that 
it allows for the best-effort streaming of both the payload being 
wrapped and of the JWS/JWS pieces. Hence I offered this idea.


As I said to Justin: I'm fine with it not being considered further, one 
can't expect every proposal being accepted :-)


Thanks for the feedback !
Sergey

On 11/11/14 17:23, John Bradley wrote:

Personally I think that sending a JWS as the body is a fine idea, though I 
would not directly tie that to POP because that are likely validated at 
different levels.  OAuth should not be in the business of extracting body 
content from the JWS.

If the RS wants to pass the key for validating the JWS body up to the 
application, and have the application validate/decrypt the body that would be 
fine in my opinion.
I think that however would be defined in another extension.

John B.


On Nov 11, 2014, at 7:12 AM, Sergey Beryozkin  wrote:


Hi Justin

I'm sorry, I've missed it

What is your opinion of having a body optionally wrapped into JWS and JWS being 
sent as a body, as an alternative (while keeping 'b' as an option too).
It can allow for streaming, as opposed to calculating the body hash in 
memory...JWS can be calculated dynamically. The key would be the same key that 
calculates the query/etc hash...

Sergey
On 11/11/14 17:05, Justin Richer wrote:

It already does offer a body hash, optional like the rest of the parameters

https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3

(see the “b” parameter)

  — Justin

On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:


On 10/11/14 16:56, John Bradley wrote:

For sending  JWE symmetric key to the client the Key Encryption Key is client 
public key provisioned out of band or pushed to the AS in the request.  (The 
same applies to key agreement)

Thanks...

I suggested earlier to consider using 'bearer' token type in the token response 
containing a 'key'; probably a bad idea, not sure now (i.e, is it still a 
'bearer', with a client now holding a PoP key :-)),

may be it should be 'pop' as documents like
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
offer.

Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
raised a related question and I wonder, should this document offer an *optional* request 
body hashing as well.

Thanks, Sergey



John B.
On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:


By the way, where is the key encryption key is obtained from in a case where 
the POP JWK key is encrypted ? Is it a client public key or some key obtained 
out of band ?

Cheers, Sergey
On 10/11/14 11:02, Sergey Beryozkin wrote:

Hi John,
Sorry for a delay,
On 07/11/14 21:27, John Bradley wrote:

Inline.
On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
wrote:


Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:

Hi all,

I read through three of the OAuth proof-of-possession documents and
made
a few minor changes here and there (mostly editorial & updated
references).

Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

While there are a few open issues I believe that these three documents
are in fairly good shape.

Is someone willing to do a review?


Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:

- it is unclear what the new token_type if any is introduced, for
example, the section 6 says no new token type is introduced, while
the symmetric example uses a "pop" value and the assymetric key
response example says:
"The new token type "public_key" is placed into the 'token_type'
parameter"

Is the new type is actually introduced and it is "pop" and the
clients making the requests to RS should use a "POP"/"pop" scheme ?

http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

uses "pop" but I'm not 100% sure...


The specs for the client accessing the RS need to define the token type.

There is likely to be more than one of those, signed message and TLS
channel binding.


I wonder, should it only be this PoP key distribution spec that would
use "pop", which is really about getting a regular token 'enhanced' with
a key. If I have AS returning a bearer token with a response containing
"token_type":"bearer", then when this AS receives a client token request
with a "token_type":"pop" it just means the bearer token to be returned
would have a key parameter bound to it.

Note IMHO it does not matter f

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread Sergey Beryozkin


On 11/11/14 17:22, Justin Richer wrote:

What you’re talking about is changing the body of your API to be a JWS 
directly, and that’s fine if your API wants to do things that way. Just define 
it as part of what your API expects — there are several out there that can do 
this. But that’s not what this work is about. This work is very explicitly 
about detaching the signing mechanism from the request itself, so that you 
don’t *have* to cram everything into a JOSE object directly. This lets you keep 
a plain JSON/XML/LISP-S-Expressions API and still be able to layer in signing 
of the request tied to an access token.
Not sure why you are talking about wrapping the body in JWS as an 
anti-layering idea specific to some API. Perfectly can be managed by 
filters before the body reaches the API.
Note - I'm not going to argue that this is how a body signature should 
be done :-), fine with me for the oauth2 signed-http-request go with an 
optional 'b' hash idea. I'm only saying it is all in memory only as far 
 as the producer is concerned...


Thanks, Sergey




  — Justin


On Nov 11, 2014, at 7:12 AM, Sergey Beryozkin  wrote:


Hi Justin

I'm sorry, I've missed it

What is your opinion of having a body optionally wrapped into JWS and JWS being 
sent as a body, as an alternative (while keeping 'b' as an option too).
It can allow for streaming, as opposed to calculating the body hash in 
memory...JWS can be calculated dynamically. The key would be the same key that 
calculates the query/etc hash...

Sergey
On 11/11/14 17:05, Justin Richer wrote:

It already does offer a body hash, optional like the rest of the parameters

https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3

(see the “b” parameter)

  — Justin

On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:


On 10/11/14 16:56, John Bradley wrote:

For sending  JWE symmetric key to the client the Key Encryption Key is client 
public key provisioned out of band or pushed to the AS in the request.  (The 
same applies to key agreement)

Thanks...

I suggested earlier to consider using 'bearer' token type in the token response 
containing a 'key'; probably a bad idea, not sure now (i.e, is it still a 
'bearer', with a client now holding a PoP key :-)),

may be it should be 'pop' as documents like
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
offer.

Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
raised a related question and I wonder, should this document offer an *optional* request 
body hashing as well.

Thanks, Sergey



John B.
On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:


By the way, where is the key encryption key is obtained from in a case where 
the POP JWK key is encrypted ? Is it a client public key or some key obtained 
out of band ?

Cheers, Sergey
On 10/11/14 11:02, Sergey Beryozkin wrote:

Hi John,
Sorry for a delay,
On 07/11/14 21:27, John Bradley wrote:

Inline.
On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
wrote:


Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:

Hi all,

I read through three of the OAuth proof-of-possession documents and
made
a few minor changes here and there (mostly editorial & updated
references).

Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

While there are a few open issues I believe that these three documents
are in fairly good shape.

Is someone willing to do a review?


Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:

- it is unclear what the new token_type if any is introduced, for
example, the section 6 says no new token type is introduced, while
the symmetric example uses a "pop" value and the assymetric key
response example says:
"The new token type "public_key" is placed into the 'token_type'
parameter"

Is the new type is actually introduced and it is "pop" and the
clients making the requests to RS should use a "POP"/"pop" scheme ?

http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

uses "pop" but I'm not 100% sure...


The specs for the client accessing the RS need to define the token type.

There is likely to be more than one of those, signed message and TLS
channel binding.


I wonder, should it only be this PoP key distribution spec that would
use "pop", which is really about getting a regular token 'enhanced' with
a key. If I have AS returning a bearer token with a response containing
"token_type":"bearer", then when this AS receives a client token request
with a "token_type":"pop" it just means the bearer token to be returned
would have a key parameter bound to it.

Note IMHO it does not matter for the client whether the actual token
representation is JWT or an index, it is still a "token_type":"bearer"
as far as the client getting a token response is concerned.
So it won't lead

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread John Bradley

Personally I think that sending a JWS as the body is a fine idea, though I 
would not directly tie that to POP because that are likely validated at 
different levels.  OAuth should not be in the business of extracting body 
content from the JWS.

If the RS wants to pass the key for validating the JWS body up to the 
application, and have the application validate/decrypt the body that would be 
fine in my opinion.
I think that however would be defined in another extension.

John B.


On Nov 11, 2014, at 7:12 AM, Sergey Beryozkin  wrote:

> Hi Justin
> 
> I'm sorry, I've missed it
> 
> What is your opinion of having a body optionally wrapped into JWS and JWS 
> being sent as a body, as an alternative (while keeping 'b' as an option too).
> It can allow for streaming, as opposed to calculating the body hash in 
> memory...JWS can be calculated dynamically. The key would be the same key 
> that calculates the query/etc hash...
> 
> Sergey
> On 11/11/14 17:05, Justin Richer wrote:
>> It already does offer a body hash, optional like the rest of the parameters
>> 
>> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3
>> 
>> (see the “b” parameter)
>> 
>>  — Justin
>> 
>> On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:
>> 
>>> On 10/11/14 16:56, John Bradley wrote:
 For sending  JWE symmetric key to the client the Key Encryption Key is 
 client public key provisioned out of band or pushed to the AS in the 
 request.  (The same applies to key agreement)
>>> Thanks...
>>> 
>>> I suggested earlier to consider using 'bearer' token type in the token 
>>> response containing a 'key'; probably a bad idea, not sure now (i.e, is it 
>>> still a 'bearer', with a client now holding a PoP key :-)),
>>> 
>>> may be it should be 'pop' as documents like
>>> http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
>>> offer.
>>> 
>>> Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
>>> raised a related question and I wonder, should this document offer an 
>>> *optional* request body hashing as well.
>>> 
>>> Thanks, Sergey
>>> 
 
 John B.
 On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:
 
> By the way, where is the key encryption key is obtained from in a case 
> where the POP JWK key is encrypted ? Is it a client public key or some 
> key obtained out of band ?
> 
> Cheers, Sergey
> On 10/11/14 11:02, Sergey Beryozkin wrote:
>> Hi John,
>> Sorry for a delay,
>> On 07/11/14 21:27, John Bradley wrote:
>>> Inline.
>>> On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
>>> wrote:
>>> 
 Hi
 On 26/06/14 13:42, Hannes Tschofenig wrote:
> Hi all,
> 
> I read through three of the OAuth proof-of-possession documents and
> made
> a few minor changes here and there (mostly editorial & updated
> references).
> 
> Here are the three docs:
> http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
> 
> While there are a few open issues I believe that these three documents
> are in fairly good shape.
> 
> Is someone willing to do a review?
> 
 Few comments to
 https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:
 
 - it is unclear what the new token_type if any is introduced, for
 example, the section 6 says no new token type is introduced, while
 the symmetric example uses a "pop" value and the assymetric key
 response example says:
 "The new token type "public_key" is placed into the 'token_type'
 parameter"
 
 Is the new type is actually introduced and it is "pop" and the
 clients making the requests to RS should use a "POP"/"pop" scheme ?
 
 http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
 
 uses "pop" but I'm not 100% sure...
>>> 
>>> The specs for the client accessing the RS need to define the token type.
>>> 
>>> There is likely to be more than one of those, signed message and TLS
>>> channel binding.
>>> 
>> I wonder, should it only be this PoP key distribution spec that would
>> use "pop", which is really about getting a regular token 'enhanced' with
>> a key. If I have AS returning a bearer token with a response containing
>> "token_type":"bearer", then when this AS receives a client token request
>> with a "token_type":"pop" it just means the bearer token to be returned
>> would have a key parameter bound to it.
>> 
>> Note IMHO it does not matter for the client whether the actual token
>> representation is JWT or an index, it is still a "token_type":"bearer"
>>>

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread Justin Richer

What you’re talking about is changing the body of your API to be a JWS 
directly, and that’s fine if your API wants to do things that way. Just define 
it as part of what your API expects — there are several out there that can do 
this. But that’s not what this work is about. This work is very explicitly 
about detaching the signing mechanism from the request itself, so that you 
don’t *have* to cram everything into a JOSE object directly. This lets you keep 
a plain JSON/XML/LISP-S-Expressions API and still be able to layer in signing 
of the request tied to an access token.

 — Justin


On Nov 11, 2014, at 7:12 AM, Sergey Beryozkin  wrote:

> Hi Justin
> 
> I'm sorry, I've missed it
> 
> What is your opinion of having a body optionally wrapped into JWS and JWS 
> being sent as a body, as an alternative (while keeping 'b' as an option too).
> It can allow for streaming, as opposed to calculating the body hash in 
> memory...JWS can be calculated dynamically. The key would be the same key 
> that calculates the query/etc hash...
> 
> Sergey
> On 11/11/14 17:05, Justin Richer wrote:
>> It already does offer a body hash, optional like the rest of the parameters
>> 
>> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3
>> 
>> (see the “b” parameter)
>> 
>>  — Justin
>> 
>> On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:
>> 
>>> On 10/11/14 16:56, John Bradley wrote:
 For sending  JWE symmetric key to the client the Key Encryption Key is 
 client public key provisioned out of band or pushed to the AS in the 
 request.  (The same applies to key agreement)
>>> Thanks...
>>> 
>>> I suggested earlier to consider using 'bearer' token type in the token 
>>> response containing a 'key'; probably a bad idea, not sure now (i.e, is it 
>>> still a 'bearer', with a client now holding a PoP key :-)),
>>> 
>>> may be it should be 'pop' as documents like
>>> http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
>>> offer.
>>> 
>>> Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
>>> raised a related question and I wonder, should this document offer an 
>>> *optional* request body hashing as well.
>>> 
>>> Thanks, Sergey
>>> 
 
 John B.
 On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:
 
> By the way, where is the key encryption key is obtained from in a case 
> where the POP JWK key is encrypted ? Is it a client public key or some 
> key obtained out of band ?
> 
> Cheers, Sergey
> On 10/11/14 11:02, Sergey Beryozkin wrote:
>> Hi John,
>> Sorry for a delay,
>> On 07/11/14 21:27, John Bradley wrote:
>>> Inline.
>>> On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
>>> wrote:
>>> 
 Hi
 On 26/06/14 13:42, Hannes Tschofenig wrote:
> Hi all,
> 
> I read through three of the OAuth proof-of-possession documents and
> made
> a few minor changes here and there (mostly editorial & updated
> references).
> 
> Here are the three docs:
> http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
> 
> While there are a few open issues I believe that these three documents
> are in fairly good shape.
> 
> Is someone willing to do a review?
> 
 Few comments to
 https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:
 
 - it is unclear what the new token_type if any is introduced, for
 example, the section 6 says no new token type is introduced, while
 the symmetric example uses a "pop" value and the assymetric key
 response example says:
 "The new token type "public_key" is placed into the 'token_type'
 parameter"
 
 Is the new type is actually introduced and it is "pop" and the
 clients making the requests to RS should use a "POP"/"pop" scheme ?
 
 http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
 
 uses "pop" but I'm not 100% sure...
>>> 
>>> The specs for the client accessing the RS need to define the token type.
>>> 
>>> There is likely to be more than one of those, signed message and TLS
>>> channel binding.
>>> 
>> I wonder, should it only be this PoP key distribution spec that would
>> use "pop", which is really about getting a regular token 'enhanced' with
>> a key. If I have AS returning a bearer token with a response containing
>> "token_type":"bearer", then when this AS receives a client token request
>> with a "token_type":"pop" it just means the bearer token to be returned
>> would have a key parameter bound to it.
>> 
>> Note IMHO it does not matter for the clien

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread John Bradley

The token type is about the client RS binding.   It is up to the specs like 
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0 to register 
the token types.   It may be possable for more than one binding to use the same 
token type, but that is up to them.

The term "token type" in retrospect may be slightly confusing in that the same 
AT format, may have multiple token types registered depending on the bindings.

By definition bearer an POP are mutually exclusive types of bindings.

The body hash is an option, but can be quite difficult for implementations in 
practice.  

John B.


On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:

> On 10/11/14 16:56, John Bradley wrote:
>> For sending  JWE symmetric key to the client the Key Encryption Key is 
>> client public key provisioned out of band or pushed to the AS in the 
>> request.  (The same applies to key agreement)
> Thanks...
> 
> I suggested earlier to consider using 'bearer' token type in the token 
> response containing a 'key'; probably a bad idea, not sure now (i.e, is it 
> still a 'bearer', with a client now holding a PoP key :-)),
> 
> may be it should be 'pop' as documents like
> http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
> offer.
> 
> Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
> raised a related question and I wonder, should this document offer an 
> *optional* request body hashing as well.
> 
> Thanks, Sergey
> 
>> 
>> John B.
>> On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:
>> 
>>> By the way, where is the key encryption key is obtained from in a case 
>>> where the POP JWK key is encrypted ? Is it a client public key or some key 
>>> obtained out of band ?
>>> 
>>> Cheers, Sergey
>>> On 10/11/14 11:02, Sergey Beryozkin wrote:
 Hi John,
 Sorry for a delay,
 On 07/11/14 21:27, John Bradley wrote:
> Inline.
> On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
> wrote:
> 
>> Hi
>> On 26/06/14 13:42, Hannes Tschofenig wrote:
>>> Hi all,
>>> 
>>> I read through three of the OAuth proof-of-possession documents and
>>> made
>>> a few minor changes here and there (mostly editorial & updated
>>> references).
>>> 
>>> Here are the three docs:
>>> http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
>>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
>>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
>>> 
>>> While there are a few open issues I believe that these three documents
>>> are in fairly good shape.
>>> 
>>> Is someone willing to do a review?
>>> 
>> Few comments to
>> https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:
>> 
>> - it is unclear what the new token_type if any is introduced, for
>> example, the section 6 says no new token type is introduced, while
>> the symmetric example uses a "pop" value and the assymetric key
>> response example says:
>> "The new token type "public_key" is placed into the 'token_type'
>> parameter"
>> 
>> Is the new type is actually introduced and it is "pop" and the
>> clients making the requests to RS should use a "POP"/"pop" scheme ?
>> 
>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
>> 
>> uses "pop" but I'm not 100% sure...
> 
> The specs for the client accessing the RS need to define the token type.
> 
> There is likely to be more than one of those, signed message and TLS
> channel binding.
> 
 I wonder, should it only be this PoP key distribution spec that would
 use "pop", which is really about getting a regular token 'enhanced' with
 a key. If I have AS returning a bearer token with a response containing
 "token_type":"bearer", then when this AS receives a client token request
 with a "token_type":"pop" it just means the bearer token to be returned
 would have a key parameter bound to it.
 
 Note IMHO it does not matter for the client whether the actual token
 representation is JWT or an index, it is still a "token_type":"bearer"
 as far as the client getting a token response is concerned.
 So it won't lead to the proliferation of the new token types.
 
 Something else that I wanted to suggest - can make no much sense but
 here it goes:
 
 Refresh tokens and indeed id_token OIDC tokens are just access token
 response parameters but for them to be included in the response all what
 is needed is for the client to include an extra scope in the redirection
 request... Just a thought...
 
 
> I am guessing that the channel binding one wouldn't support symmetric
> proof keys.
> 
> Those specs may wind up profiling this spec to limit particular key
> types etc.
> 
> The token_type  in the request is saying give me a token to use

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread Sergey Beryozkin


Hi Justin

I'm sorry, I've missed it

What is your opinion of having a body optionally wrapped into JWS and 
JWS being sent as a body, as an alternative (while keeping 'b' as an 
option too).
It can allow for streaming, as opposed to calculating the body hash in 
memory...JWS can be calculated dynamically. The key would be the same 
key that calculates the query/etc hash...


Sergey
On 11/11/14 17:05, Justin Richer wrote:

It already does offer a body hash, optional like the rest of the parameters

https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3

(see the “b” parameter)

  — Justin

On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:


On 10/11/14 16:56, John Bradley wrote:

For sending  JWE symmetric key to the client the Key Encryption Key is client 
public key provisioned out of band or pushed to the AS in the request.  (The 
same applies to key agreement)

Thanks...

I suggested earlier to consider using 'bearer' token type in the token response 
containing a 'key'; probably a bad idea, not sure now (i.e, is it still a 
'bearer', with a client now holding a PoP key :-)),

may be it should be 'pop' as documents like
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
offer.

Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
raised a related question and I wonder, should this document offer an *optional* request 
body hashing as well.

Thanks, Sergey



John B.
On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:


By the way, where is the key encryption key is obtained from in a case where 
the POP JWK key is encrypted ? Is it a client public key or some key obtained 
out of band ?

Cheers, Sergey
On 10/11/14 11:02, Sergey Beryozkin wrote:

Hi John,
Sorry for a delay,
On 07/11/14 21:27, John Bradley wrote:

Inline.
On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
wrote:


Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:

Hi all,

I read through three of the OAuth proof-of-possession documents and
made
a few minor changes here and there (mostly editorial & updated
references).

Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

While there are a few open issues I believe that these three documents
are in fairly good shape.

Is someone willing to do a review?


Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:

- it is unclear what the new token_type if any is introduced, for
example, the section 6 says no new token type is introduced, while
the symmetric example uses a "pop" value and the assymetric key
response example says:
"The new token type "public_key" is placed into the 'token_type'
parameter"

Is the new type is actually introduced and it is "pop" and the
clients making the requests to RS should use a "POP"/"pop" scheme ?

http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

uses "pop" but I'm not 100% sure...


The specs for the client accessing the RS need to define the token type.

There is likely to be more than one of those, signed message and TLS
channel binding.


I wonder, should it only be this PoP key distribution spec that would
use "pop", which is really about getting a regular token 'enhanced' with
a key. If I have AS returning a bearer token with a response containing
"token_type":"bearer", then when this AS receives a client token request
with a "token_type":"pop" it just means the bearer token to be returned
would have a key parameter bound to it.

Note IMHO it does not matter for the client whether the actual token
representation is JWT or an index, it is still a "token_type":"bearer"
as far as the client getting a token response is concerned.
So it won't lead to the proliferation of the new token types.

Something else that I wanted to suggest - can make no much sense but
here it goes:

Refresh tokens and indeed id_token OIDC tokens are just access token
response parameters but for them to be included in the response all what
is needed is for the client to include an extra scope in the redirection
request... Just a thought...



I am guessing that the channel binding one wouldn't support symmetric
proof keys.

Those specs may wind up profiling this spec to limit particular key
types etc.

The token_type  in the request is saying give me a token to use over
this request method to the RS.

The AS might use the same logic to produce a AT for signed request and
TLS.

The other parameters are:
"aud" so that the AS can deal with multiple RS perhaps all with
different encryption keys and some using introspection.
"alg" indicating the alg of the proof key "HS256", "RS256", and
"ECDSA"  being the current likely options.
(looking at that now I wonder if we also need to say anything about
key length/curve,  I hope all of that can be sorted out in
registration so some sensible defaults woul

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread Justin Richer

It already does offer a body hash, optional like the rest of the parameters

https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3

(see the “b” parameter)

 — Justin

On Nov 11, 2014, at 12:47 AM, Sergey Beryozkin  wrote:

> On 10/11/14 16:56, John Bradley wrote:
>> For sending  JWE symmetric key to the client the Key Encryption Key is 
>> client public key provisioned out of band or pushed to the AS in the 
>> request.  (The same applies to key agreement)
> Thanks...
> 
> I suggested earlier to consider using 'bearer' token type in the token 
> response containing a 'key'; probably a bad idea, not sure now (i.e, is it 
> still a 'bearer', with a client now holding a PoP key :-)),
> 
> may be it should be 'pop' as documents like
> http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
> offer.
> 
> Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine 
> raised a related question and I wonder, should this document offer an 
> *optional* request body hashing as well.
> 
> Thanks, Sergey
> 
>> 
>> John B.
>> On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:
>> 
>>> By the way, where is the key encryption key is obtained from in a case 
>>> where the POP JWK key is encrypted ? Is it a client public key or some key 
>>> obtained out of band ?
>>> 
>>> Cheers, Sergey
>>> On 10/11/14 11:02, Sergey Beryozkin wrote:
 Hi John,
 Sorry for a delay,
 On 07/11/14 21:27, John Bradley wrote:
> Inline.
> On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
> wrote:
> 
>> Hi
>> On 26/06/14 13:42, Hannes Tschofenig wrote:
>>> Hi all,
>>> 
>>> I read through three of the OAuth proof-of-possession documents and
>>> made
>>> a few minor changes here and there (mostly editorial & updated
>>> references).
>>> 
>>> Here are the three docs:
>>> http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
>>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
>>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
>>> 
>>> While there are a few open issues I believe that these three documents
>>> are in fairly good shape.
>>> 
>>> Is someone willing to do a review?
>>> 
>> Few comments to
>> https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:
>> 
>> - it is unclear what the new token_type if any is introduced, for
>> example, the section 6 says no new token type is introduced, while
>> the symmetric example uses a "pop" value and the assymetric key
>> response example says:
>> "The new token type "public_key" is placed into the 'token_type'
>> parameter"
>> 
>> Is the new type is actually introduced and it is "pop" and the
>> clients making the requests to RS should use a "POP"/"pop" scheme ?
>> 
>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
>> 
>> uses "pop" but I'm not 100% sure...
> 
> The specs for the client accessing the RS need to define the token type.
> 
> There is likely to be more than one of those, signed message and TLS
> channel binding.
> 
 I wonder, should it only be this PoP key distribution spec that would
 use "pop", which is really about getting a regular token 'enhanced' with
 a key. If I have AS returning a bearer token with a response containing
 "token_type":"bearer", then when this AS receives a client token request
 with a "token_type":"pop" it just means the bearer token to be returned
 would have a key parameter bound to it.
 
 Note IMHO it does not matter for the client whether the actual token
 representation is JWT or an index, it is still a "token_type":"bearer"
 as far as the client getting a token response is concerned.
 So it won't lead to the proliferation of the new token types.
 
 Something else that I wanted to suggest - can make no much sense but
 here it goes:
 
 Refresh tokens and indeed id_token OIDC tokens are just access token
 response parameters but for them to be included in the response all what
 is needed is for the client to include an extra scope in the redirection
 request... Just a thought...
 
 
> I am guessing that the channel binding one wouldn't support symmetric
> proof keys.
> 
> Those specs may wind up profiling this spec to limit particular key
> types etc.
> 
> The token_type  in the request is saying give me a token to use over
> this request method to the RS.
> 
> The AS might use the same logic to produce a AT for signed request and
> TLS.
> 
> The other parameters are:
> "aud" so that the AS can deal with multiple RS perhaps all with
> different encryption keys and some using introspection.
> "alg" indicating the alg of the proof key "HS256", "RS256", and
> "ECDSA"  being the current likel

Re: [OAUTH-WG] Updated OAuth PoP documents

2014-11-11 Thread Sergey Beryozkin


On 10/11/14 16:56, John Bradley wrote:

For sending  JWE symmetric key to the client the Key Encryption Key is client 
public key provisioned out of band or pushed to the AS in the request.  (The 
same applies to key agreement)

Thanks...

I suggested earlier to consider using 'bearer' token type in the token 
response containing a 'key'; probably a bad idea, not sure now (i.e, is 
it still a 'bearer', with a client now holding a PoP key :-)),


may be it should be 'pop' as documents like
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
offer.

Speaking of "draft-richer-oauth-signed-http-request" - a colleague of 
mine raised a related question and I wonder, should this document offer 
an *optional* request body hashing as well.


Thanks, Sergey



John B.
On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin  wrote:


By the way, where is the key encryption key is obtained from in a case where 
the POP JWK key is encrypted ? Is it a client public key or some key obtained 
out of band ?

Cheers, Sergey
On 10/11/14 11:02, Sergey Beryozkin wrote:

Hi John,
Sorry for a delay,
On 07/11/14 21:27, John Bradley wrote:

Inline.
On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin 
wrote:


Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:

Hi all,

I read through three of the OAuth proof-of-possession documents and
made
a few minor changes here and there (mostly editorial & updated
references).

Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

While there are a few open issues I believe that these three documents
are in fairly good shape.

Is someone willing to do a review?


Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:

- it is unclear what the new token_type if any is introduced, for
example, the section 6 says no new token type is introduced, while
the symmetric example uses a "pop" value and the assymetric key
response example says:
"The new token type "public_key" is placed into the 'token_type'
parameter"

Is the new type is actually introduced and it is "pop" and the
clients making the requests to RS should use a "POP"/"pop" scheme ?

http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

uses "pop" but I'm not 100% sure...


The specs for the client accessing the RS need to define the token type.

There is likely to be more than one of those, signed message and TLS
channel binding.


I wonder, should it only be this PoP key distribution spec that would
use "pop", which is really about getting a regular token 'enhanced' with
a key. If I have AS returning a bearer token with a response containing
"token_type":"bearer", then when this AS receives a client token request
with a "token_type":"pop" it just means the bearer token to be returned
would have a key parameter bound to it.

Note IMHO it does not matter for the client whether the actual token
representation is JWT or an index, it is still a "token_type":"bearer"
as far as the client getting a token response is concerned.
So it won't lead to the proliferation of the new token types.

Something else that I wanted to suggest - can make no much sense but
here it goes:

Refresh tokens and indeed id_token OIDC tokens are just access token
response parameters but for them to be included in the response all what
is needed is for the client to include an extra scope in the redirection
request... Just a thought...



I am guessing that the channel binding one wouldn't support symmetric
proof keys.

Those specs may wind up profiling this spec to limit particular key
types etc.

The token_type  in the request is saying give me a token to use over
this request method to the RS.

The AS might use the same logic to produce a AT for signed request and
TLS.

The other parameters are:
"aud" so that the AS can deal with multiple RS perhaps all with
different encryption keys and some using introspection.
"alg" indicating the alg of the proof key "HS256", "RS256", and
"ECDSA"  being the current likely options.
(looking at that now I wonder if we also need to say anything about
key length/curve,  I hope all of that can be sorted out in
registration so some sensible defaults would work for length/curve)

Those being important to any client RS protocol.


thanks for this extra info,




- The assymetric key example suggests that just a JWS-signed access
token is returned. This implies a client can easily introspect it -
which is not a big problem in this case - but it leads the client
toward writing a code that is bound to an access token structure -
therefore such a client code won't inter-operate with the AS sending
a bearer token; IMHO the access token structure should absolutely be
opaque to the clients, i.e, if it is JWT then it must be JWE protected


The intention is not to limit it to just JWS signed JWT, that should
be expanded if no

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

Re: [OAUTH-WG] Updated OAuth PoP documents

13 matches

Site Navigation

Mail list logo

Footer information