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

2014-11-11 Thread Mike Jones
t;; Pete Resnick; oauth; The IESG; oauth-cha...@tools.ietf.org<mailto: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

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

2014-11-11 Thread Richard Barnes
rian 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'

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

2014-11-11 Thread Mike Jones
...@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 o

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

2014-10-17 Thread John Bradley
+1 On Oct 17, 2014, at 3:23 PM, Brian Campbell wrote: > 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

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

2014-10-17 Thread Brian Campbell
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.or

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

2014-10-17 Thread Richard Barnes
un...@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Friday, October 17, 2014 9:50 AM > *To:* John Bradley > *Cc:* draft-ietf-oauth-asserti...@tools.ietf.org; Richard Barnes; > oauth-cha...@tools.ietf.org; The IESG; oauth > *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on > d

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

2014-10-17 Thread Richard Barnes
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

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

2014-10-17 Thread Kathleen Moriarty
I just caught up on the thread again and think Brian's message below may be the most helpful to resolve this discuss. It sounds like we have agreement that a MUST is preferred for bearer tokens and that's what this draft is about. Would a language tweak help when HoK is mentioned? The WG wi

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

2014-10-17 Thread Phil Hunt
FWIW…I was only responding to the question of making aud optional for bearer tokens. The broader point is that regardless of token type, there is always an “aud” value — whether explicitly declared as a claim, or implicitly implied (e.g. through encryption so only the audience can consume it).

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

2014-10-17 Thread John Bradley
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,

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

2014-10-17 Thread Pete Resnick
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,

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

2014-10-17 Thread Mike Jones
9:50 AM To: John Bradley Cc: draft-ietf-oauth-asserti...@tools.ietf.org; Richard Barnes; oauth-cha...@tools.ietf.org; The IESG; oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) I believe that if you make "aud" opt

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

2014-10-17 Thread Phil Hunt
I believe that if you make “aud” optional, it only helps the simplistic deployment scenarios where there is only one RS and one AS. The optionality itself will cause more confusion. In the simplistic case, the AS and RS simply have to agree on a URI. In more sophisticated domains where there i

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

2014-10-17 Thread John Bradley
I am good with it as is. I think we have the flexibility to add HoK later. I mostly wanted to point out that it is really only in that later HoK profile where omitting audience is safe. If I had the power to remove the DISCUS I would. John B. On Oct 17, 2014, at 12:56 PM, Brian Campbell

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

2014-10-17 Thread Brian Campbell
These drafts define the use of bearer assertions. The only mention of HoK style assertions is at the end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which notes that the "rules defined in this document are intended to support a client presenting a bearer assertion to an

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

2014-10-16 Thread John Bradley
Holder of key JWT is still in draft and we don't have a clear way to present the proof to the token endpoint. Brian and I started discussing that last week as I happen to have a use case for a PoP JWT assertion flow in some other spec work. I think that there is enough difference between bearer

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

2014-10-16 Thread Richard Barnes
On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes wrote: > You guys are all arguing that having an Audience can be useful. I don't > disagree. I disagree that it should be REQUIRED in all cases. > > The Google vulnerability that Brian raised was an interesting read, but as > John points out, it o

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

2014-10-16 Thread Richard Barnes
You guys are all arguing that having an Audience can be useful. I don't disagree. I disagree that it should be REQUIRED in all cases. The Google vulnerability that Brian raised was an interesting read, but as John points out, it only applies to Bearer Assertions. There's no security requirement

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

2014-10-16 Thread Phil Hunt
It is also important for a non-protocol purpose. Liability. If a 3rd party uses an assertion that was not intended for it, it cannot obviously hold the asserting party responsible. Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 16, 2014, at 8:43 AM, Brian Campbell w

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

2014-10-16 Thread John Bradley
rg; > > oauth@ietf.org > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > > draft-ietf-oauth-assertions-17: > > (with DISCUSS and COMMENT) > > > > Richard Barnes has entered the following ballot position for > > draft-ietf-oauth-assertions-17: Discus

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

2014-10-16 Thread Brian Campbell
Thanks for your review and feedback, Richard. Replies are inline below... On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss > > When responding, please keep the subject line intact and r

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

2014-10-16 Thread Richard Barnes
auth-boun...@ietf.org] On Behalf Of Richard Barnes > > Sent: Wednesday, October 15, 2014 8:48 PM > > To: The IESG > > Cc: draft-ietf-oauth-asserti...@tools.ietf.org; > oauth-cha...@tools.ietf.org; > > oauth@ietf.org > > Subject: [OAUTH-WG] Richard Barnes' Disc

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

2014-10-16 Thread Mike Jones
, 2014 8:48 PM > To: The IESG > Cc: draft-ietf-oauth-asserti...@tools.ietf.org; oauth-cha...@tools.ietf.org; > oauth@ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: > (with DISCUSS and COMMENT) > > Richard Barnes has entered the fo

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

2014-10-15 Thread Richard Barnes
Richard Barnes has entered the following ballot position for draft-ietf-oauth-assertions-17: 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 htt