[OAUTH-WG] FW: JOSE -35 and JWT -29 drafts addressing AppsDir review comments

[Mike Jones]

From: Mike Jones
Sent: Friday, October 17, 2014 6:32 PM
To: j...@ietf.org
Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments

I've posted updated JOSE and JWT drafts that address the Applications Area 
Directorate review comments.  Thanks to Ray Polk and Carsten Bormann for their 
useful reviews.  No breaking changes were made.

The specifications are available at:

* http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35

* http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-35

* http://tools.ietf.org/html/draft-ietf-jose-json-web-key-35

* http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-35

* http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29

HTML formatted versions are available at:

* 
http://self-issued.info/docs/draft-ietf-jose-json-web-signature-35.html

* 
http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-35.html

* http://self-issued.info/docs/draft-ietf-jose-json-web-key-35.html

* 
http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-35.html

* http://self-issued.info/docs/draft-ietf-oauth-json-web-token-29.html

-- Mike

P.S.  I've also posted this notice at http://self-issued.info/?p=1293 and as 
@selfissued.

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-29.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : JSON Web Token (JWT)
Authors : Michael B. Jones
  John Bradley
  Nat Sakimura
Filename: draft-ietf-oauth-json-web-token-29.txt
Pages   : 34
Date: 2014-10-17

Abstract:
   JSON Web Token (JWT) is a compact, URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JavaScript Object Notation (JSON) object that is
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-29


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)

[Brian Campbell]

Stephen,

I'm working on updating these drafts and as I look again at the text that's
in §5. Interoperability Considerations and the requirement in §3 Assertion
Format and Processing Requirements to compare these values using the Simple
String Comparison (absent an application profile specifying otherwise) I'm
not sure what to say or where based on your suggestion below. Is there
something specific you can suggest (and where to put it)?

Thanks,
Brian

On Thu, Oct 16, 2014 at 3:20 PM, Brian Campbell 
wrote:

>
> On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>>
>> > Some stuff needs to be exchanged out-of-band for this to work.
>> > Entity/issuer/audience identifiers are part of that. This need is
>> discussed
>> > in the Interoperability Considerations at
>> > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5
>>
>> So I think it'd be good to explicitly call out that these
>> mappings are basically required and that they can be fraught
>> (e.g. if someone uses wildcards badly, which they do).
>>
>
> OK, I will add something to that effect in the next revisions.
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Secdir Review of draft-ietf-oauth-jwt-bearer-10

[Brian Campbell]

I agree with mike that any additional guidance on when you'd want to use an
assertion for client authentication vs. when you would want to use one for
an authorization grant would belong in the generic assertions specification
draft-ietf-oauth-assertions.

I'm struggling with what guidance to give about it, however. Maybe I'm just
too close to things but it seems almost definitional - one is for client
auth and the other is an authz grant.

Radia (or really anyone), is there some specific text you can propose?


On Mon, Oct 6, 2014 at 1:54 AM, Mike Jones 
wrote:

> Thanks for your review, Radia.  I've added the working group to the thread
> so that they're aware of your comments.
>
> > From: Radia Perlman [mailto:radiaperl...@gmail.com]
> > Some background guidance on when you would want to use a token for
> client authentication vs. when you would want to use one for an
> authorization grant would be useful. In practice, the distinction between
> the two is subtle. It is common for a token to contain the caller’s
> identity as well as group memberships and perhaps roles. I suspect the
> reality is that the client has to figure out which protocol slot the server
> wants to get the token in and provide it there, where service designers
> make the decision more or less arbitrarily.
>
> This guidance really belongs in the generic assertions specification
> draft-ietf-oauth-assertions.  I'll plan on reviewing that spec with the
> other editors and the working group to see whether the guidance provided
> there needs to be improved.
>
>
___
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)

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

[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.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] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

[Richard Barnes]

On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell 
wrote:

>
>
> On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes  wrote:
>
>>
>>
>> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Thanks for your review and feedback on this one too, Richard. Replies
>>> are inline below...
>>>
>>> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes  wrote:
>>>
 Richard Barnes has entered the following ballot position for
 draft-ietf-oauth-jwt-bearer-10: 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-jwt-bearer/



 --
 DISCUSS:
 --

 As with draft-ietf-oauth-assertions, the requirement for an "aud" claim
 seems entirely unnecessary.  Holding this DISCUSS point pending that
 discussion
 and its reflection in this document.

 "Assertions that do not identify the Authorization Server as an intended
 audience MUST be rejected." -- What does it mean for an assertion to
 "identify
 the Authorization Server"?  Does the specified  need to match
 the
 entire URL of the relevant OAuth endpoint?  Just the origin?  Just the
 domain?
 Does the URL need to be canonicalized?


>>>
>>> No c14n, as it says, "...  compare the audience values using the Simple
>>> String Comparison method defined in Section 6.2.1 of RFC 3986."
>>>
>>> Basically the AS is at liberty to determine how it identifies itself.
>>> Some guidance on using the token endpoint is provided but it's ultimately
>>> up to the AS (or the larger deployment in which the AS exists). The
>>> acceptable value is one of a few bits of information that must be exchanged
>>> for this profile, which is discussed in the Interoperability Considerations
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5
>>>
>>
>> Sigh.  "Negotiate it out of band" is a terrible, non-scalable,
>> not-in-the-spirit-of-the-Internet answer.  But I guess I might clear on
>> this if you could add something like the following:
>> "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise
>> strings to be used as the Audience for a given Authorization Server must be
>> configured out-of-band by the Authorization Server and the Issuer of the
>> assertion."
>>
>
>
>
> I'll add the suggested text.
>

Great.  Let me know when the revised text is posted.

--Richard



>
>
>
>>
>> But is there seriously no answer that the WG could agree on?  This seems
>> like it should be a pretty simple question.  Was it even discussed?
>>
>>
>
>
> It was discussed but it's not simple for reasons I've tried to articulate
> many times.
>
> Note that the specific profiling or usage of these specs can constrain or
> dictate the values of this and other the things that needing out of band
> negotiation and can be more in the spirit of the Internet to the extent
> that they define dynamic exchange/discovery/registration/etc. of required
> information. But these little documents need to fit into such larger
> contexts not try and define them.
>
>
>
>> --Richard
>>
>>
>>
>>> Some more explanation/discussion of it is in the middle(ish) of this
>>> reply to a similar comment from Stephen Farrell
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html
>>>
>>>
>>>
 --
 COMMENT:
 --

 "keyed message digest" -> "MAC"

>>>
>>> Yep.
>>>
>>>

 Both this and the SAML document could save a lot of bits by just being
 subsections of the -assertions document.

>>>
>>> The structure and relationship of the documents was decided on by the WG
>>> nearly three years ago. There is some duplication but it's believed to be
>>> more approachable this way - particularly for those implementing just one
>>> assertion type.
>>>
>>
>>
>
___
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)

[Richard Barnes]

It's a known set of actual attacks ... on bearer assertions.  There is no
corresponding attack on HoK assertions.

We shouldn't consider making it optional for bearer assertions.  For HoK,
there's no reason for it not to be optional.

On Fri, Oct 17, 2014 at 10:09 AM, Mike Jones 
wrote:

>  +1
>
>
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@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
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> 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 is more than one RS service, the
> “aud” value is expected and is useful to determining who a token is
> intended for.
>
>
>
> Finally, there is the 3rd level case where the AS and the RS are in
> separate domains (federated). In this case, we can expect inter-op to be
> required between separate vendors as a majority of cases.
>
>
>
> Making “aud” optional will greatly increase complexity in reality.  Making
> it a MUST only puts a trivial imposition on the trivial case (they have to
> provide a made up URI).
>
>
>
> We did not really discuss “aud" much on the list because it is well known
> industry practice. I would not want to suggest re-writing something that
> works well.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On Oct 17, 2014, at 9:01 AM, John Bradley  wrote:
>
>
>
>  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 
> wrote:
>
>
>
>   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 authorization server.
> The use of holder-of-key assertions are not precluded by this document, but
> additional protocol details would need to be specified."
>
> The requirement of having audience is for bearer assertions only (and we
> agree need to be that way for bearer) and not intended to preclude anything
> for HoK assertions.
>
> Does that change your opinion? Is there something that could be added or
> removed or clarified to allay concerns?
>
>
>
>
>
> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>
> 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 and PoP that doing
> a follow on profile for SAML and JWT that can also cover the proof
> presentment mechanisms makes the most sense.
>
>
>
> I would go with restricting this to Bearer and MUST for audience,  and
> removing the audience requirement explicitly in the PoP profiles.
>
>
>
> There are people who need the bearer version 6 months ago,  I don't want
> to do anything to hold it up based on future work.
>
>
>
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML
> subject confirmation stuff is relatively clear so it is mostly defining the
> presentment mechanisms like mutual TLS and a self signed assertion. (we
> need to be careful not to conflate client authentication and token proof,
> as they are different and might both be used at the same time.
>
>
>
> John B.
>
>
>
> On Oct 16, 2014, at 7: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 only applies to Bearer Assertions.  There's no security
> requirement at all for holder-of-key assertions to have an audience, since
> they can't be replayed by someone who doesn't hold the key.
>
> I could agree that an audience should be REQUIRED for bearer assertions.
> Since they are vulnerable to replay, Audience protects against the
> Authorizat

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

[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 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

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

[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 will have more time to figure out what is needed for that in 
the draft mentioned that is on development.

Thanks,
Kathleen 

Sent from my iPhone

> On Oct 17, 2014, at 11:56 AM, Brian Campbell  
> wrote:
> 
> 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 authorization server.  The use of 
> holder-of-key assertions are not precluded by this document, but additional 
> protocol details would need to be specified."
> 
> The requirement of having audience is for bearer assertions only (and we 
> agree need to be that way for bearer) and not intended to preclude anything 
> for HoK assertions. 
> 
> Does that change your opinion? Is there something that could be added or 
> removed or clarified to allay concerns?
> 
> 
> 
>> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>> 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 and PoP that doing a 
>> follow on profile for SAML and JWT that can also cover the proof presentment 
>> mechanisms makes the most sense.
>> 
>> I would go with restricting this to Bearer and MUST for audience,  and 
>> removing the audience requirement explicitly in the PoP profiles.
>> 
>> There are people who need the bearer version 6 months ago,  I don't want to 
>> do anything to hold it up based on future work.
>> 
>> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML 
>> subject confirmation stuff is relatively clear so it is mostly defining the 
>> presentment mechanisms like mutual TLS and a self signed assertion. (we need 
>> to be careful not to conflate client authentication and token proof, as they 
>> are different and might both be used at the same time.
>> 
>> John B.
>> 
>>> On Oct 16, 2014, at 7: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 only applies to Bearer Assertions.  There's no security 
>>> requirement at all for holder-of-key assertions to have an audience, since 
>>> they can't be replayed by someone who doesn't hold the key.
>>> 
>>> I could agree that an audience should be REQUIRED for bearer assertions.  
>>> Since they are vulnerable to replay, Audience protects against the 
>>> Authorization Server re-using the token.  (It would be good to say this 
>>> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
>>> Audience should be OPTIONAL.  Note that this requires that instance 
>>> documents define the difference between bearer assertions and holder-of-key 
>>> assertions, so that implementations can enforce these requirements.
>>> 
>>> So it seems like there are two solutions here:
>>> 1. Scope the document to bearer assertions only, and keep the MUST
>>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
>>> assertions, and define the difference in the instance docs.
>>> 
>>> --Richard
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
 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  
> wrote:
> 
> 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 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 

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

[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).

Phil

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



On Oct 17, 2014, at 10:25 AM, 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

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

[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, 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.

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

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

[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, 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

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

[Mike Jones]

+1

This is the standard mitigation for a known set of actual attacks.  We 
shouldn't even consider making it optional.

-- Mike

From: OAuth [mailto:oauth-boun...@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 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

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 is more than one RS service, the 
"aud" value is expected and is useful to determining who a token is intended 
for.

Finally, there is the 3rd level case where the AS and the RS are in separate 
domains (federated). In this case, we can expect inter-op to be required 
between separate vendors as a majority of cases.

Making "aud" optional will greatly increase complexity in reality.  Making it a 
MUST only puts a trivial imposition on the trivial case (they have to provide a 
made up URI).

We did not really discuss "aud" much on the list because it is well known 
industry practice. I would not want to suggest re-writing something that works 
well.

Phil

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



On Oct 17, 2014, at 9:01 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:


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 
mailto:bcampb...@pingidentity.com>> wrote:


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 authorization server.  The use of 
holder-of-key assertions are not precluded by this document, but additional 
protocol details would need to be specified."
The requirement of having audience is for bearer assertions only (and we agree 
need to be that way for bearer) and not intended to preclude anything for HoK 
assertions.
Does that change your opinion? Is there something that could be added or 
removed or clarified to allay concerns?


On Thu, Oct 16, 2014 at 6:54 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
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 and PoP that doing a 
follow on profile for SAML and JWT that can also cover the proof presentment 
mechanisms makes the most sense.

I would go with restricting this to Bearer and MUST for audience,  and removing 
the audience requirement explicitly in the PoP profiles.

There are people who need the bearer version 6 months ago,  I don't want to do 
anything to hold it up based on future work.

I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML subject 
confirmation stuff is relatively clear so it is mostly defining the presentment 
mechanisms like mutual TLS and a self signed assertion. (we need to be careful 
not to conflate client authentication and token proof, as they are different 
and might both be used at the same time.

John B.

On Oct 16, 2014, at 7:20 PM, Richard Barnes mailto:r...@ipv.sx>> 
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 only applies to Bearer Assertions.  There's no security 
requirement at all for holder-of-key assertions to have an audience, since they 
can't be replayed by someone who doesn't hold the key.
I could agree that an audience should be REQUIRED for bearer assertions.  Since 
they are vulnerable to replay, Audience protects against the Authorization 
Server re-using the token.  (It would be good to say this explicitly in the 
doc, actually.)  But for holder-of-key assertions, the Audience should be 
OPTIONAL.  Note that this requires that instance documents define the 
difference between bearer assertions and holder-of-key assertions, so that 
implementations can enforce these requirements.
So it seems like there are two solutions here:
1. Scop

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

[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 is more than one RS service, the 
“aud” value is expected and is useful to determining who a token is intended 
for.

Finally, there is the 3rd level case where the AS and the RS are in separate 
domains (federated). In this case, we can expect inter-op to be required 
between separate vendors as a majority of cases.  

Making “aud” optional will greatly increase complexity in reality.  Making it a 
MUST only puts a trivial imposition on the trivial case (they have to provide a 
made up URI).

We did not really discuss “aud" much on the list because it is well known 
industry practice. I would not want to suggest re-writing something that works 
well.

Phil

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



On Oct 17, 2014, at 9:01 AM, John Bradley  wrote:

> 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  
> wrote:
> 
>> 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 authorization server.  The use of 
>> holder-of-key assertions are not precluded by this document, but additional 
>> protocol details would need to be specified."
>> 
>> The requirement of having audience is for bearer assertions only (and we 
>> agree need to be that way for bearer) and not intended to preclude anything 
>> for HoK assertions. 
>> 
>> Does that change your opinion? Is there something that could be added or 
>> removed or clarified to allay concerns?
>> 
>> 
>> 
>> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>> 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 and PoP that doing a 
>> follow on profile for SAML and JWT that can also cover the proof presentment 
>> mechanisms makes the most sense.
>> 
>> I would go with restricting this to Bearer and MUST for audience,  and 
>> removing the audience requirement explicitly in the PoP profiles.
>> 
>> There are people who need the bearer version 6 months ago,  I don't want to 
>> do anything to hold it up based on future work.
>> 
>> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML 
>> subject confirmation stuff is relatively clear so it is mostly defining the 
>> presentment mechanisms like mutual TLS and a self signed assertion. (we need 
>> to be careful not to conflate client authentication and token proof, as they 
>> are different and might both be used at the same time.
>> 
>> John B.
>> 
>> On Oct 16, 2014, at 7: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 only applies to Bearer Assertions.  There's no security 
>>> requirement at all for holder-of-key assertions to have an audience, since 
>>> they can't be replayed by someone who doesn't hold the key.
>>> 
>>> I could agree that an audience should be REQUIRED for bearer assertions.  
>>> Since they are vulnerable to replay, Audience protects against the 
>>> Authorization Server re-using the token.  (It would be good to say this 
>>> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
>>> Audience should be OPTIONAL.  Note that this requires that instance 
>>> documents define the difference between bearer assertions and holder-of-key 
>>> assertions, so that implementations can enforce these requirements.
>>> 
>>> So it seems like there are two solutions here:
>>> 1. Scope the document to bearer assertions only, and keep the MUST
>>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
>>> assertions, and define the difference in the instance docs.
>>> 
>>> --Richard
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>>> 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 

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)

[Brian Campbell]

Touché... ;)

On Thu, Oct 16, 2014 at 4:36 PM, Richard Barnes  wrote:

> That's what you get for duplicating all the text :)
>
> On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> Basically the same response to the basically same question as from
>> http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html
>>
>> On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes  wrote:
>>
>>> Richard Barnes has entered the following ballot position for
>>> draft-ietf-oauth-saml2-bearer-21: 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-saml2-bearer/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> As with draft-ietf-oauth-assertions, the requirement for an 
>>> element seems entirely unnecessary.  Holding this DISCUSS point pending
>>> that discussion and its reflection in this document.
>>>
>>> "Assertions that do not identify the Authorization Server as an intended
>>> audience MUST be rejected." -- What does it mean for an assertion to
>>> "identify the Authorization Server"?  Does the specified  need
>>> to match the entire URL of the relevant OAuth endpoint?  Just the origin?
>>>  Just the domain?  Does the URL need to be canonicalized?
>>>
>>>
>>>
>>>
>>> ___
>>> 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-jwt-bearer-10: (with DISCUSS and COMMENT)

[Brian Campbell]

On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes  wrote:

>
>
> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> Thanks for your review and feedback on this one too, Richard. Replies
>> are inline below...
>>
>> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes  wrote:
>>
>>> Richard Barnes has entered the following ballot position for
>>> draft-ietf-oauth-jwt-bearer-10: 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-jwt-bearer/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim
>>> seems entirely unnecessary.  Holding this DISCUSS point pending that
>>> discussion
>>> and its reflection in this document.
>>>
>>> "Assertions that do not identify the Authorization Server as an intended
>>> audience MUST be rejected." -- What does it mean for an assertion to
>>> "identify
>>> the Authorization Server"?  Does the specified  need to match
>>> the
>>> entire URL of the relevant OAuth endpoint?  Just the origin?  Just the
>>> domain?
>>> Does the URL need to be canonicalized?
>>>
>>>
>>
>> No c14n, as it says, "...  compare the audience values using the Simple
>> String Comparison method defined in Section 6.2.1 of RFC 3986."
>>
>> Basically the AS is at liberty to determine how it identifies itself.
>> Some guidance on using the token endpoint is provided but it's ultimately
>> up to the AS (or the larger deployment in which the AS exists). The
>> acceptable value is one of a few bits of information that must be exchanged
>> for this profile, which is discussed in the Interoperability Considerations
>> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5
>>
>
> Sigh.  "Negotiate it out of band" is a terrible, non-scalable,
> not-in-the-spirit-of-the-Internet answer.  But I guess I might clear on
> this if you could add something like the following:
> "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings
> to be used as the Audience for a given Authorization Server must be
> configured out-of-band by the Authorization Server and the Issuer of the
> assertion."
>



I'll add the suggested text.




>
> But is there seriously no answer that the WG could agree on?  This seems
> like it should be a pretty simple question.  Was it even discussed?
>
>


It was discussed but it's not simple for reasons I've tried to articulate
many times.

Note that the specific profiling or usage of these specs can constrain or
dictate the values of this and other the things that needing out of band
negotiation and can be more in the spirit of the Internet to the extent
that they define dynamic exchange/discovery/registration/etc. of required
information. But these little documents need to fit into such larger
contexts not try and define them.




> --Richard
>
>
>
>> Some more explanation/discussion of it is in the middle(ish) of this
>> reply to a similar comment from Stephen Farrell
>> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html
>>
>>
>>
>>> --
>>> COMMENT:
>>> --
>>>
>>> "keyed message digest" -> "MAC"
>>>
>>
>> Yep.
>>
>>
>>>
>>> Both this and the SAML document could save a lot of bits by just being
>>> subsections of the -assertions document.
>>>
>>
>> The structure and relationship of the documents was decided on by the WG
>> nearly three years ago. There is some duplication but it's believed to be
>> more approachable this way - particularly for those implementing just one
>> assertion type.
>>
>
>
___
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)

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

> 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 authorization server.  The use of 
> holder-of-key assertions are not precluded by this document, but additional 
> protocol details would need to be specified."
> 
> The requirement of having audience is for bearer assertions only (and we 
> agree need to be that way for bearer) and not intended to preclude anything 
> for HoK assertions. 
> 
> Does that change your opinion? Is there something that could be added or 
> removed or clarified to allay concerns?
> 
> 
> 
> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
> 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 and PoP that doing a 
> follow on profile for SAML and JWT that can also cover the proof presentment 
> mechanisms makes the most sense.
> 
> I would go with restricting this to Bearer and MUST for audience,  and 
> removing the audience requirement explicitly in the PoP profiles.
> 
> There are people who need the bearer version 6 months ago,  I don't want to 
> do anything to hold it up based on future work.
> 
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML 
> subject confirmation stuff is relatively clear so it is mostly defining the 
> presentment mechanisms like mutual TLS and a self signed assertion. (we need 
> to be careful not to conflate client authentication and token proof, as they 
> are different and might both be used at the same time.
> 
> John B.
> 
> On Oct 16, 2014, at 7: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 only applies to Bearer Assertions.  There's no security 
>> requirement at all for holder-of-key assertions to have an audience, since 
>> they can't be replayed by someone who doesn't hold the key.
>> 
>> I could agree that an audience should be REQUIRED for bearer assertions.  
>> Since they are vulnerable to replay, Audience protects against the 
>> Authorization Server re-using the token.  (It would be good to say this 
>> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
>> Audience should be OPTIONAL.  Note that this requires that instance 
>> documents define the difference between bearer assertions and holder-of-key 
>> assertions, so that implementations can enforce these requirements.
>> 
>> So it seems like there are two solutions here:
>> 1. Scope the document to bearer assertions only, and keep the MUST
>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
>> assertions, and define the difference in the instance docs.
>> 
>> --Richard
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>> 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  
>> wrote:
>> 
>>> 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 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-assertions/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> "The assertion MUST contain an Audience that identifies 

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

[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 authorization server.  The use
of holder-of-key assertions are not precluded by this document, but
additional protocol details would need to be specified."

The requirement of having audience is for bearer assertions only (and we
agree need to be that way for bearer) and not intended to preclude anything
for HoK assertions.

Does that change your opinion? Is there something that could be added or
removed or clarified to allay concerns?



On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:

> 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 and PoP that doing
> a follow on profile for SAML and JWT that can also cover the proof
> presentment mechanisms makes the most sense.
>
> I would go with restricting this to Bearer and MUST for audience,  and
> removing the audience requirement explicitly in the PoP profiles.
>
> There are people who need the bearer version 6 months ago,  I don't want
> to do anything to hold it up based on future work.
>
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML
> subject confirmation stuff is relatively clear so it is mostly defining the
> presentment mechanisms like mutual TLS and a self signed assertion. (we
> need to be careful not to conflate client authentication and token proof,
> as they are different and might both be used at the same time.
>
> John B.
>
> On Oct 16, 2014, at 7: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 only applies to Bearer Assertions.  There's no security
> requirement at all for holder-of-key assertions to have an audience, since
> they can't be replayed by someone who doesn't hold the key.
>
> I could agree that an audience should be REQUIRED for bearer assertions.
> Since they are vulnerable to replay, Audience protects against the
> Authorization Server re-using the token.  (It would be good to say this
> explicitly in the doc, actually.)  But for holder-of-key assertions, the
> Audience should be OPTIONAL.  Note that this requires that instance
> documents define the difference between bearer assertions and holder-of-key
> assertions, so that implementations can enforce these requirements.
>
> So it seems like there are two solutions here:
> 1. Scope the document to bearer assertions only, and keep the MUST
> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key
> assertions, and define the difference in the instance docs.
>
> --Richard
>
>
>
>
>
>
> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>
>> 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 
>> wrote:
>>
>> 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 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-assertions/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> "The assertion MUST contain an Audience that identifies the Authorization
>>> Server as the intended audience.  Assertions that do not identify the
>>> Authorization Server as an intended audience MUST be rejected."
>>>
>>> Could you please identify the threat model within which this "MUST" is
>>> required?  This requirement doesn't follow from any of the threats
>>> elaborated in Section 8.
>>>
>>> The Audience is only necessary if the Issuer wishes to constrain the set
>>> of Authorization

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Sergey Beryozkin]

Hi
On 17/10/14 16:13, John Bradley wrote:

Are you saying that the OIDC filter/client can set session cookies in a domain 
that other web servers can use, so they don't have to have any direct knowledge 
of Connect.

Yes. It is a pity I was not able to express myself with a single 
sentence like you offered above :-)

I suspect that is a common practice in many SSO implementations.   It is true 
that not every web server needs to implement connect itself for SSO.
Right; I guess it would make sense to make it a bit more obvious in some 
docs, may be in Opend id Connect Intro or similar


Thanks, Sergey


John B.
On Oct 17, 2014, at 11:57 AM, Sergey Beryozkin  wrote:


Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:

- should a few words be reserved for the client credentials flow - this is of 
course not a mainstream OAuth2 nor its related to OIDC but it is all about the 
authentication IMHO, the clients get their tokens by simply getting 
authenticated, and as far as legacy (code) clients are concerned they 'migrate' 
from sending the name/password to the resource endpoint on every request ?


The client credentials flow has nothing to do with user authentication, which 
is why it's left out of OIDC. There might not even be a user in this flow (and 
it's generally assumed that there isn't).


Yes, it is not part of OIDC but it is still the authentication of the client 
that is effectively a resource owner, no human user is involved but IMHO it's 
still very much the authentication. Exactly what the coded clients do today in 
non OAuth2 client-server communications, except that in this case the 
name/password is offered only once to AS.
May be it was not what this flow was envisaged for originally but I do like it 
for the reasons outlined above, specifically it can help the legacy/traditional 
clients to 'join' the OAuth2 AS infrastructure


But it's not authentication of the *user*, which is the whole point. When the client 
authenticates on its own behalf, you have no idea who the user is or if they exist. It's 
irrelevant to the user authentication flow. If you're looking for pulling legacy clients 
in, the "password" flow is better for that, but OIDC didn't profile it because 
people really shouldn't be using the password flow except in very limited use cases in 
the first place.


I did get that. See the notes are about "OAuth2 & Authentication", so I thought 
it would not only be about the human user being authenticated via OIDC.
OAuth2 has different flows with some of them requiring no human user being 
around, and the client_credentials flow is all about authenticating the client 
giving the token back for it to access its own resources, except that not 
having to sent name/password every time.
This client does not need to be aware of any users because effectively this 
client is a 'user'.
If "OAuth2 & Authentication" implies the human user is involved then may be it 
would be clearer if the subject was reworded somehow...
Either way, if you reckon the client-credentials are out of scope then I'm fine 
with that, I guess keeping it focused on OIDC will help with the message






- IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, 
i.e one does not have to write an OAuth2 client web application to get the 
benefits of the OIDC-driven authentication


I don't understand what you're saying here. In order to make an OIDC RP, you 
need to write an OAuth2 client. That's by design.

OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 
client which actually does some application specific work, right ?
I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the 
server 'protected' by this RP which would work with the authenticated user does 
not have to be OAuth2 client, do you agree ?
If OIDC RP could only be used alongside OAuth2 clients then it would limit its 
usefulness IMHO



But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. 
Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have 
an OIDC client that isn't also an OAuth client because OIDC is built directly 
on top of OAuth.


May be it is my language issues. I haven't suggested that OIDC can be 
implemented without it being OAuth2 client.

Consider this:

OIDC RP filter <-> non OAuth2 server

OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the 
user to OIDC IDP, validate the response) and then set the security context and 
let the user go to the non OAuth2 (client) server, with this server not being 
even aware that the OIDC flow has happened.

Am not making sense at all with the above ?

Thanks, Sergey





  -- Justin





Cheers, Sergey




  -- Justin



Thanks, Sergey
On 16/10/14 17:54, Hannes Tschofenig wrote:

Participants:

  * Brian Campbell
  * John Bradley
  * Derek Atkins
  * Phil Hunt
  * William Kim
  * Josh Mandel
  * Hannes Tschofenig


Notes:

Justin distributed a draft writeup and exp

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Sergey Beryozkin]

Hi,
On 17/10/14 16:11, Richer, Justin P. wrote:


On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin  wrote:


Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:

- should a few words be reserved for the client credentials flow - this is of 
course not a mainstream OAuth2 nor its related to OIDC but it is all about the 
authentication IMHO, the clients get their tokens by simply getting 
authenticated, and as far as legacy (code) clients are concerned they 'migrate' 
from sending the name/password to the resource endpoint on every request ?


The client credentials flow has nothing to do with user authentication, which 
is why it's left out of OIDC. There might not even be a user in this flow (and 
it's generally assumed that there isn't).


Yes, it is not part of OIDC but it is still the authentication of the client 
that is effectively a resource owner, no human user is involved but IMHO it's 
still very much the authentication. Exactly what the coded clients do today in 
non OAuth2 client-server communications, except that in this case the 
name/password is offered only once to AS.
May be it was not what this flow was envisaged for originally but I do like it 
for the reasons outlined above, specifically it can help the legacy/traditional 
clients to 'join' the OAuth2 AS infrastructure


But it's not authentication of the *user*, which is the whole point. When the client 
authenticates on its own behalf, you have no idea who the user is or if they exist. It's 
irrelevant to the user authentication flow. If you're looking for pulling legacy clients 
in, the "password" flow is better for that, but OIDC didn't profile it because 
people really shouldn't be using the password flow except in very limited use cases in 
the first place.


I did get that. See the notes are about "OAuth2 & Authentication", so I thought 
it would not only be about the human user being authenticated via OIDC.
OAuth2 has different flows with some of them requiring no human user being 
around, and the client_credentials flow is all about authenticating the client 
giving the token back for it to access its own resources, except that not 
having to sent name/password every time.
This client does not need to be aware of any users because effectively this 
client is a 'user'.
If "OAuth2 & Authentication" implies the human user is involved then may be it 
would be clearer if the subject was reworded somehow...
Either way, if you reckon the client-credentials are out of scope then I'm fine 
with that, I guess keeping it focused on OIDC will help with the message


Interesting, that's a misinterpretation that I didn't anticipate. I think I'm going to 
rename the whole page "OAuth and User Authentication" to avoid that.

To be clear, the notes did not confuse me :-), it is obvious they are 
about having the user involved in the authorization code/implicit flows 
involved, I just thought may be the doc can be enhanced further to cover 
various OAuth2 situations where the 'authentication' is involved.

Yea, "OAuth2 and User Authentication" is a good subject name IMHO







- IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, 
i.e one does not have to write an OAuth2 client web application to get the 
benefits of the OIDC-driven authentication


I don't understand what you're saying here. In order to make an OIDC RP, you 
need to write an OAuth2 client. That's by design.

OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 
client which actually does some application specific work, right ?
I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the 
server 'protected' by this RP which would work with the authenticated user does 
not have to be OAuth2 client, do you agree ?
If OIDC RP could only be used alongside OAuth2 clients then it would limit its 
usefulness IMHO



But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. 
Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have 
an OIDC client that isn't also an OAuth client because OIDC is built directly 
on top of OAuth.


May be it is my language issues. I haven't suggested that OIDC can be 
implemented without it being OAuth2 client.

Consider this:

OIDC RP filter <-> non OAuth2 server

OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the 
user to OIDC IDP, validate the response) and then set the security context and 
let the user go to the non OAuth2 (client) server, with this server not being 
even aware that the OIDC flow has happened.

Am not making sense at all with the above ?


I think I see what you're saying now -- you could have a client that 
authenticates the user through OIDC and also accesses some set of non-identity 
APIs through OAuth, and the two parts don't actually have to talk to each 
other. That's fine, but it's such a deep implementation detail that I don't 
think it helps the conversation that we're trying to have. Especially 
co

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[John Bradley]

Are you saying that the OIDC filter/client can set session cookies in a domain 
that other web servers can use, so they don't have to have any direct knowledge 
of Connect.

I suspect that is a common practice in many SSO implementations.   It is true 
that not every web server needs to implement connect itself for SSO.

John B.
On Oct 17, 2014, at 11:57 AM, Sergey Beryozkin  wrote:

> Hi,
> On 17/10/14 15:09, Richer, Justin P. wrote:
> - should a few words be reserved for the client credentials flow - this 
> is of course not a mainstream OAuth2 nor its related to OIDC but it is 
> all about the authentication IMHO, the clients get their tokens by simply 
> getting authenticated, and as far as legacy (code) clients are concerned 
> they 'migrate' from sending the name/password to the resource endpoint on 
> every request ?
 
 The client credentials flow has nothing to do with user authentication, 
 which is why it's left out of OIDC. There might not even be a user in this 
 flow (and it's generally assumed that there isn't).
 
>>> Yes, it is not part of OIDC but it is still the authentication of the 
>>> client that is effectively a resource owner, no human user is involved but 
>>> IMHO it's still very much the authentication. Exactly what the coded 
>>> clients do today in non OAuth2 client-server communications, except that in 
>>> this case the name/password is offered only once to AS.
>>> May be it was not what this flow was envisaged for originally but I do like 
>>> it for the reasons outlined above, specifically it can help the 
>>> legacy/traditional clients to 'join' the OAuth2 AS infrastructure
>> 
>> But it's not authentication of the *user*, which is the whole point. When 
>> the client authenticates on its own behalf, you have no idea who the user is 
>> or if they exist. It's irrelevant to the user authentication flow. If you're 
>> looking for pulling legacy clients in, the "password" flow is better for 
>> that, but OIDC didn't profile it because people really shouldn't be using 
>> the password flow except in very limited use cases in the first place.
> 
> I did get that. See the notes are about "OAuth2 & Authentication", so I 
> thought it would not only be about the human user being authenticated via 
> OIDC.
> OAuth2 has different flows with some of them requiring no human user being 
> around, and the client_credentials flow is all about authenticating the 
> client giving the token back for it to access its own resources, except that 
> not having to sent name/password every time.
> This client does not need to be aware of any users because effectively this 
> client is a 'user'.
> If "OAuth2 & Authentication" implies the human user is involved then may be 
> it would be clearer if the subject was reworded somehow...
> Either way, if you reckon the client-credentials are out of scope then I'm 
> fine with that, I guess keeping it focused on OIDC will help with the message
> 
>> 
>>> 
> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 
> servers, i.e one does not have to write an OAuth2 client web application 
> to get the benefits of the OIDC-driven authentication
 
 I don't understand what you're saying here. In order to make an OIDC RP, 
 you need to write an OAuth2 client. That's by design.
>>> OIDC RP is a client. But this RP doe snot have to be collocated with the 
>>> OAuth2 client which actually does some application specific work, right ?
>>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the 
>>> server 'protected' by this RP which would work with the authenticated user 
>>> does not have to be OAuth2 client, do you agree ?
>>> If OIDC RP could only be used alongside OAuth2 clients then it would limit 
>>> its usefulness IMHO
>> 
>> 
>> But the OIDC RP *is* an OAuth Client, so I still don't get what you're 
>> saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you 
>> can't have an OIDC client that isn't also an OAuth client because OIDC is 
>> built directly on top of OAuth.
> 
> May be it is my language issues. I haven't suggested that OIDC can be 
> implemented without it being OAuth2 client.
> 
> Consider this:
> 
> OIDC RP filter <-> non OAuth2 server
> 
> OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the 
> user to OIDC IDP, validate the response) and then set the security context 
> and let the user go to the non OAuth2 (client) server, with this server not 
> being even aware that the OIDC flow has happened.
> 
> Am not making sense at all with the above ?
> 
> Thanks, Sergey
> 
> 
> 
>> 
>>  -- Justin
>> 
>> 
>> 
>>> 
>>> Cheers, Sergey
>>> 
>>> 
 
  -- Justin
 
> 
> Thanks, Sergey
> On 16/10/14 17:54, Hannes Tschofenig wrote:
>> Participants:
>> 
>>  * Brian Campbell
>>  * John Bradley
>>  * Derek Atkins
>>  * Phil Hunt
>>  * William Kim
>>  * Josh Ma

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Richer, Justin P.]

On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin  wrote:

> Hi,
> On 17/10/14 15:09, Richer, Justin P. wrote:
> - should a few words be reserved for the client credentials flow - this 
> is of course not a mainstream OAuth2 nor its related to OIDC but it is 
> all about the authentication IMHO, the clients get their tokens by simply 
> getting authenticated, and as far as legacy (code) clients are concerned 
> they 'migrate' from sending the name/password to the resource endpoint on 
> every request ?
 
 The client credentials flow has nothing to do with user authentication, 
 which is why it's left out of OIDC. There might not even be a user in this 
 flow (and it's generally assumed that there isn't).
 
>>> Yes, it is not part of OIDC but it is still the authentication of the 
>>> client that is effectively a resource owner, no human user is involved but 
>>> IMHO it's still very much the authentication. Exactly what the coded 
>>> clients do today in non OAuth2 client-server communications, except that in 
>>> this case the name/password is offered only once to AS.
>>> May be it was not what this flow was envisaged for originally but I do like 
>>> it for the reasons outlined above, specifically it can help the 
>>> legacy/traditional clients to 'join' the OAuth2 AS infrastructure
>> 
>> But it's not authentication of the *user*, which is the whole point. When 
>> the client authenticates on its own behalf, you have no idea who the user is 
>> or if they exist. It's irrelevant to the user authentication flow. If you're 
>> looking for pulling legacy clients in, the "password" flow is better for 
>> that, but OIDC didn't profile it because people really shouldn't be using 
>> the password flow except in very limited use cases in the first place.
> 
> I did get that. See the notes are about "OAuth2 & Authentication", so I 
> thought it would not only be about the human user being authenticated via 
> OIDC.
> OAuth2 has different flows with some of them requiring no human user being 
> around, and the client_credentials flow is all about authenticating the 
> client giving the token back for it to access its own resources, except that 
> not having to sent name/password every time.
> This client does not need to be aware of any users because effectively this 
> client is a 'user'.
> If "OAuth2 & Authentication" implies the human user is involved then may be 
> it would be clearer if the subject was reworded somehow...
> Either way, if you reckon the client-credentials are out of scope then I'm 
> fine with that, I guess keeping it focused on OIDC will help with the message

Interesting, that's a misinterpretation that I didn't anticipate. I think I'm 
going to rename the whole page "OAuth and User Authentication" to avoid that.

> 
>> 
>>> 
> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 
> servers, i.e one does not have to write an OAuth2 client web application 
> to get the benefits of the OIDC-driven authentication
 
 I don't understand what you're saying here. In order to make an OIDC RP, 
 you need to write an OAuth2 client. That's by design.
>>> OIDC RP is a client. But this RP doe snot have to be collocated with the 
>>> OAuth2 client which actually does some application specific work, right ?
>>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the 
>>> server 'protected' by this RP which would work with the authenticated user 
>>> does not have to be OAuth2 client, do you agree ?
>>> If OIDC RP could only be used alongside OAuth2 clients then it would limit 
>>> its usefulness IMHO
>> 
>> 
>> But the OIDC RP *is* an OAuth Client, so I still don't get what you're 
>> saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you 
>> can't have an OIDC client that isn't also an OAuth client because OIDC is 
>> built directly on top of OAuth.
> 
> May be it is my language issues. I haven't suggested that OIDC can be 
> implemented without it being OAuth2 client.
> 
> Consider this:
> 
> OIDC RP filter <-> non OAuth2 server
> 
> OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the 
> user to OIDC IDP, validate the response) and then set the security context 
> and let the user go to the non OAuth2 (client) server, with this server not 
> being even aware that the OIDC flow has happened.
> 
> Am not making sense at all with the above ?

I think I see what you're saying now -- you could have a client that 
authenticates the user through OIDC and also accesses some set of non-identity 
APIs through OAuth, and the two parts don't actually have to talk to each 
other. That's fine, but it's such a deep implementation detail that I don't 
think it helps the conversation that we're trying to have. Especially 
considering that the real problem stems from developers who do both 
authentication and authorized API access right side by side in the same code 
and get 

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Sergey Beryozkin]

Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:

- should a few words be reserved for the client credentials flow - this is of 
course not a mainstream OAuth2 nor its related to OIDC but it is all about the 
authentication IMHO, the clients get their tokens by simply getting 
authenticated, and as far as legacy (code) clients are concerned they 'migrate' 
from sending the name/password to the resource endpoint on every request ?


The client credentials flow has nothing to do with user authentication, which 
is why it's left out of OIDC. There might not even be a user in this flow (and 
it's generally assumed that there isn't).


Yes, it is not part of OIDC but it is still the authentication of the client 
that is effectively a resource owner, no human user is involved but IMHO it's 
still very much the authentication. Exactly what the coded clients do today in 
non OAuth2 client-server communications, except that in this case the 
name/password is offered only once to AS.
May be it was not what this flow was envisaged for originally but I do like it 
for the reasons outlined above, specifically it can help the legacy/traditional 
clients to 'join' the OAuth2 AS infrastructure


But it's not authentication of the *user*, which is the whole point. When the client 
authenticates on its own behalf, you have no idea who the user is or if they exist. It's 
irrelevant to the user authentication flow. If you're looking for pulling legacy clients 
in, the "password" flow is better for that, but OIDC didn't profile it because 
people really shouldn't be using the password flow except in very limited use cases in 
the first place.


I did get that. See the notes are about "OAuth2 & Authentication", so I 
thought it would not only be about the human user being authenticated 
via OIDC.
OAuth2 has different flows with some of them requiring no human user 
being around, and the client_credentials flow is all about 
authenticating the client giving the token back for it to access its own 
resources, except that not having to sent name/password every time.
This client does not need to be aware of any users because effectively 
this client is a 'user'.
If "OAuth2 & Authentication" implies the human user is involved then may 
be it would be clearer if the subject was reworded somehow...
Either way, if you reckon the client-credentials are out of scope then 
I'm fine with that, I guess keeping it focused on OIDC will help with 
the message







- IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, 
i.e one does not have to write an OAuth2 client web application to get the 
benefits of the OIDC-driven authentication


I don't understand what you're saying here. In order to make an OIDC RP, you 
need to write an OAuth2 client. That's by design.

OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 
client which actually does some application specific work, right ?
I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the 
server 'protected' by this RP which would work with the authenticated user does 
not have to be OAuth2 client, do you agree ?
If OIDC RP could only be used alongside OAuth2 clients then it would limit its 
usefulness IMHO



But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. 
Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have 
an OIDC client that isn't also an OAuth client because OIDC is built directly 
on top of OAuth.


May be it is my language issues. I haven't suggested that OIDC can be 
implemented without it being OAuth2 client.


Consider this:

OIDC RP filter <-> non OAuth2 server

OIDC RP filter would do the OIDC thing (will act as OAuth2 client, 
return the user to OIDC IDP, validate the response) and then set the 
security context and let the user go to the non OAuth2 (client) server, 
with this server not being even aware that the OIDC flow has happened.


Am not making sense at all with the above ?

Thanks, Sergey





  -- Justin





Cheers, Sergey




  -- Justin



Thanks, Sergey
On 16/10/14 17:54, Hannes Tschofenig wrote:

Participants:

  * Brian Campbell
  * John Bradley
  * Derek Atkins
  * Phil Hunt
  * William Kim
  * Josh Mandel
  * Hannes Tschofenig


Notes:

Justin distributed a draft writeup and explained the reasoning behind
it. The intended purpose is to put the write-up (after enough review) on
oauth.net. See attachments. Justin solicited feedback from the
conference call participants and from the working group.

One discussion item was specifically related to the concept of audience
restrictions, which comes in two flavours: (a) restriction of the access
token regarding the resource server and (b) restriction of the id token
regarding the client. Obviously, it is necessary to have both of these
audience restrictions in place and to actually check them.

The group then went into a discussion about the use of pseudonyms in
authentication and the problems 

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Richer, Justin P.]

>>> - should a few words be reserved for the client credentials flow - this is 
>>> of course not a mainstream OAuth2 nor its related to OIDC but it is all 
>>> about the authentication IMHO, the clients get their tokens by simply 
>>> getting authenticated, and as far as legacy (code) clients are concerned 
>>> they 'migrate' from sending the name/password to the resource endpoint on 
>>> every request ?
>> 
>> The client credentials flow has nothing to do with user authentication, 
>> which is why it's left out of OIDC. There might not even be a user in this 
>> flow (and it's generally assumed that there isn't).
>> 
> Yes, it is not part of OIDC but it is still the authentication of the client 
> that is effectively a resource owner, no human user is involved but IMHO it's 
> still very much the authentication. Exactly what the coded clients do today 
> in non OAuth2 client-server communications, except that in this case the 
> name/password is offered only once to AS.
> May be it was not what this flow was envisaged for originally but I do like 
> it for the reasons outlined above, specifically it can help the 
> legacy/traditional clients to 'join' the OAuth2 AS infrastructure

But it's not authentication of the *user*, which is the whole point. When the 
client authenticates on its own behalf, you have no idea who the user is or if 
they exist. It's irrelevant to the user authentication flow. If you're looking 
for pulling legacy clients in, the "password" flow is better for that, but OIDC 
didn't profile it because people really shouldn't be using the password flow 
except in very limited use cases in the first place. 

> 
>>> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 
>>> servers, i.e one does not have to write an OAuth2 client web application to 
>>> get the benefits of the OIDC-driven authentication
>> 
>> I don't understand what you're saying here. In order to make an OIDC RP, you 
>> need to write an OAuth2 client. That's by design.
> OIDC RP is a client. But this RP doe snot have to be collocated with the 
> OAuth2 client which actually does some application specific work, right ?
> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the 
> server 'protected' by this RP which would work with the authenticated user 
> does not have to be OAuth2 client, do you agree ?
> If OIDC RP could only be used alongside OAuth2 clients then it would limit 
> its usefulness IMHO


But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. 
Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have 
an OIDC client that isn't also an OAuth client because OIDC is built directly 
on top of OAuth.

 -- Justin



> 
> Cheers, Sergey
> 
> 
>> 
>>  -- Justin
>> 
>>> 
>>> Thanks, Sergey
>>> On 16/10/14 17:54, Hannes Tschofenig wrote:
 Participants:
 
  * Brian Campbell
  * John Bradley
  * Derek Atkins
  * Phil Hunt
  * William Kim
  * Josh Mandel
  * Hannes Tschofenig
 
 
 Notes:
 
 Justin distributed a draft writeup and explained the reasoning behind
 it. The intended purpose is to put the write-up (after enough review) on
 oauth.net. See attachments. Justin solicited feedback from the
 conference call participants and from the working group.
 
 One discussion item was specifically related to the concept of audience
 restrictions, which comes in two flavours: (a) restriction of the access
 token regarding the resource server and (b) restriction of the id token
 regarding the client. Obviously, it is necessary to have both of these
 audience restrictions in place and to actually check them.
 
 The group then went into a discussion about the use of pseudonyms in
 authentication and the problems deployments ran into when they used
 pseudonyms together with a wide range of attributes that identified
 users nevertheless. Phil suggested to produce a write-up about this topic.
 
 Finally, the group started a discussion about potential actions for the
 OAuth working groups. Two activities were mentioned, namely to produce
 an IETF draft of the write-up Justin has prepared as a "formal" response
 to the problems with authentication using OAuth and, as a second topic,
 potential re-chartering of the OAuth working group to work on some
 solutions in this area. Hannes suggested to postpone these discussions
 and to first finish the write-up Justin had distributed.
 
 Ciao
 Hannes & Derek
 
 
 
 ___
 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
>> 
> 

___
OAuth mailing list
OAuth@ietf.org
ht

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Sergey Beryozkin]

Hi,
On 17/10/14 14:33, Richer, Justin P. wrote:

On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin  wrote:


+1. I'm finding this write-up summarizing the "OAuth2 and Authentication" 
'situation' perfectly. It does help.

Minor suggestions/questions:
- might make sense to point out that an id_token can be linked to the access 
token (via at_hash), thus confirming both tokens came from the same AS


Seems a reasonable point, I can add that.


- should a 2-way TLS mentioned as a possible approach for mitigating the 
'injection of the token' attack ? I guess it won't scale really well but IMHO 
it is a useful mechanism nonetheless


It doesn't actually help in this case, since if the client is checking the 
server's certs that should be OK (or as OK as TLS can get). The real attack 
comes from someone handing the token to an application through a mechanism 
other than the return from the token endpoint, and I've seen a handful of 
applications that pass around the access token to themselves  through internal 
callback mechanisms that are a bit more exposed than they ought to be.


OK, I understand

- should a few words be reserved for the client credentials flow - this is of 
course not a mainstream OAuth2 nor its related to OIDC but it is all about the 
authentication IMHO, the clients get their tokens by simply getting 
authenticated, and as far as legacy (code) clients are concerned they 'migrate' 
from sending the name/password to the resource endpoint on every request ?


The client credentials flow has nothing to do with user authentication, which 
is why it's left out of OIDC. There might not even be a user in this flow (and 
it's generally assumed that there isn't).

Yes, it is not part of OIDC but it is still the authentication of the 
client that is effectively a resource owner, no human user is involved 
but IMHO it's still very much the authentication. Exactly what the coded 
clients do today in non OAuth2 client-server communications, except that 
in this case the name/password is offered only once to AS.
May be it was not what this flow was envisaged for originally but I do 
like it for the reasons outlined above, specifically it can help the 
legacy/traditional clients to 'join' the OAuth2 AS infrastucture



- IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, 
i.e one does not have to write an OAuth2 client web application to get the 
benefits of the OIDC-driven authentication


I don't understand what you're saying here. In order to make an OIDC RP, you 
need to write an OAuth2 client. That's by design.
OIDC RP is a client. But this RP doe snot have to be collocated with the 
OAuth2 client which actually does some application specific work, right ?
I.e OIDC RP facilitates the OAuth2-based authentication mechanism but 
the server 'protected' by this RP which would work with the 
authenticated user does not have to be OAuth2 client, do you agree ?
If OIDC RP could only be used alongside OAuth2 clients then it would 
limit its usefulness IMHO


Cheers, Sergey




  -- Justin



Thanks, Sergey
On 16/10/14 17:54, Hannes Tschofenig wrote:

Participants:

  * Brian Campbell
  * John Bradley
  * Derek Atkins
  * Phil Hunt
  * William Kim
  * Josh Mandel
  * Hannes Tschofenig


Notes:

Justin distributed a draft writeup and explained the reasoning behind
it. The intended purpose is to put the write-up (after enough review) on
oauth.net. See attachments. Justin solicited feedback from the
conference call participants and from the working group.

One discussion item was specifically related to the concept of audience
restrictions, which comes in two flavours: (a) restriction of the access
token regarding the resource server and (b) restriction of the id token
regarding the client. Obviously, it is necessary to have both of these
audience restrictions in place and to actually check them.

The group then went into a discussion about the use of pseudonyms in
authentication and the problems deployments ran into when they used
pseudonyms together with a wide range of attributes that identified
users nevertheless. Phil suggested to produce a write-up about this topic.

Finally, the group started a discussion about potential actions for the
OAuth working groups. Two activities were mentioned, namely to produce
an IETF draft of the write-up Justin has prepared as a "formal" response
to the problems with authentication using OAuth and, as a second topic,
potential re-chartering of the OAuth working group to work on some
solutions in this area. Hannes suggested to postpone these discussions
and to first finish the write-up Justin had distributed.

Ciao
Hannes & Derek



___
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




___
OAuth mailing list

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Richer, Justin P.]

On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin  wrote:

> +1. I'm finding this write-up summarizing the "OAuth2 and Authentication" 
> 'situation' perfectly. It does help.
> 
> Minor suggestions/questions:
> - might make sense to point out that an id_token can be linked to the access 
> token (via at_hash), thus confirming both tokens came from the same AS

Seems a reasonable point, I can add that.

> - should a 2-way TLS mentioned as a possible approach for mitigating the 
> 'injection of the token' attack ? I guess it won't scale really well but IMHO 
> it is a useful mechanism nonetheless

It doesn't actually help in this case, since if the client is checking the 
server's certs that should be OK (or as OK as TLS can get). The real attack 
comes from someone handing the token to an application through a mechanism 
other than the return from the token endpoint, and I've seen a handful of 
applications that pass around the access token to themselves  through internal 
callback mechanisms that are a bit more exposed than they ought to be. 

> - should a few words be reserved for the client credentials flow - this is of 
> course not a mainstream OAuth2 nor its related to OIDC but it is all about 
> the authentication IMHO, the clients get their tokens by simply getting 
> authenticated, and as far as legacy (code) clients are concerned they 
> 'migrate' from sending the name/password to the resource endpoint on every 
> request ?

The client credentials flow has nothing to do with user authentication, which 
is why it's left out of OIDC. There might not even be a user in this flow (and 
it's generally assumed that there isn't).

> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 
> servers, i.e one does not have to write an OAuth2 client web application to 
> get the benefits of the OIDC-driven authentication

I don't understand what you're saying here. In order to make an OIDC RP, you 
need to write an OAuth2 client. That's by design.

 -- Justin

> 
> Thanks, Sergey
> On 16/10/14 17:54, Hannes Tschofenig wrote:
>> Participants:
>> 
>>  * Brian Campbell
>>  * John Bradley
>>  * Derek Atkins
>>  * Phil Hunt
>>  * William Kim
>>  * Josh Mandel
>>  * Hannes Tschofenig
>> 
>> 
>> Notes:
>> 
>> Justin distributed a draft writeup and explained the reasoning behind
>> it. The intended purpose is to put the write-up (after enough review) on
>> oauth.net. See attachments. Justin solicited feedback from the
>> conference call participants and from the working group.
>> 
>> One discussion item was specifically related to the concept of audience
>> restrictions, which comes in two flavours: (a) restriction of the access
>> token regarding the resource server and (b) restriction of the id token
>> regarding the client. Obviously, it is necessary to have both of these
>> audience restrictions in place and to actually check them.
>> 
>> The group then went into a discussion about the use of pseudonyms in
>> authentication and the problems deployments ran into when they used
>> pseudonyms together with a wide range of attributes that identified
>> users nevertheless. Phil suggested to produce a write-up about this topic.
>> 
>> Finally, the group started a discussion about potential actions for the
>> OAuth working groups. Two activities were mentioned, namely to produce
>> an IETF draft of the write-up Justin has prepared as a "formal" response
>> to the problems with authentication using OAuth and, as a second topic,
>> potential re-chartering of the OAuth working group to work on some
>> solutions in this area. Hannes suggested to postpone these discussions
>> and to first finish the write-up Justin had distributed.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> 
>> 
>> ___
>> 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

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

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Sergey Beryozkin]

+1. I'm finding this write-up summarizing the "OAuth2 and 
Authentication" 'situation' perfectly. It does help.


Minor suggestions/questions:
- might make sense to point out that an id_token can be linked to the 
access token (via at_hash), thus confirming both tokens came from the 
same AS
- should a 2-way TLS mentioned as a possible approach for mitigating the 
'injection of the token' attack ? I guess it won't scale really well but 
IMHO it is a useful mechanism nonetheless
- should a few words be reserved for the client credentials flow - this 
is of course not a mainstream OAuth2 nor its related to OIDC but it is 
all about the authentication IMHO, the clients get their tokens by 
simply getting authenticated, and as far as legacy (code) clients are 
concerned they 'migrate' from sending the name/password to the resource 
endpoint on every request ?
- IMHO it would be useful to mention that OIDC RP can help non-OAuth2 
servers, i.e one does not have to write an OAuth2 client web application 
to get the benefits of the OIDC-driven auhentication


Thanks, Sergey
On 16/10/14 17:54, Hannes Tschofenig wrote:

Participants:

  * Brian Campbell
  * John Bradley
  * Derek Atkins
  * Phil Hunt
  * William Kim
  * Josh Mandel
  * Hannes Tschofenig


Notes:

Justin distributed a draft writeup and explained the reasoning behind
it. The intended purpose is to put the write-up (after enough review) on
oauth.net. See attachments. Justin solicited feedback from the
conference call participants and from the working group.

One discussion item was specifically related to the concept of audience
restrictions, which comes in two flavours: (a) restriction of the access
token regarding the resource server and (b) restriction of the id token
regarding the client. Obviously, it is necessary to have both of these
audience restrictions in place and to actually check them.

The group then went into a discussion about the use of pseudonyms in
authentication and the problems deployments ran into when they used
pseudonyms together with a wide range of attributes that identified
users nevertheless. Phil suggested to produce a write-up about this topic.

Finally, the group started a discussion about potential actions for the
OAuth working groups. Two activities were mentioned, namely to produce
an IETF draft of the write-up Justin has prepared as a "formal" response
to the problems with authentication using OAuth and, as a second topic,
potential re-chartering of the OAuth working group to work on some
solutions in this area. Hannes suggested to postpone these discussions
and to first finish the write-up Justin had distributed.

Ciao
Hannes & Derek



___
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