Re: [OAUTH-WG] [scim] Simple Federation Deployment

[Roland Hedberg]

Count me in !

> 7 apr. 2016 kl. 01:17 skrev Nov Matake :
> 
> I'm interested in too.
> 
> nov
> 
> On Apr 7, 2016, at 07:14, Mike Jones  wrote:
> 
>> For the record, I’m interested.
>>  
>> From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick
>> Sent: Tuesday, April 5, 2016 7:26 PM
>> To: Phil Hunt (IDM) 
>> Cc: s...@ietf.org; oauth@ietf.org
>> Subject: Re: [scim] Simple Federation Deployment
>>  
>> I’m talking about removing manual steps in what happens today where 
>> configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) 
>> requires is a bunch of cutting and pasting of access tokens / keys / certs 
>> and doing a bunch of  config that is error prone and unique for each 
>> relationship.
>>  
>> Don’t want to solve on the thread … looking to see if there is interest!
>>  
>> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt 
>> (IDM)"  wrote:
>>  
>> Is the idp the center of all things for these users?
>>  
>> Usually you have a provisioning system that coordinates state and uses 
>> things like scim connectors to do this. 
>>  
>> Another approach from today would be to pass a scim event to the remote 
>> provider which then decides what needs to be done to facilitate the thingd 
>> you describe. 
>>  
>> Iow. Either the idp (sender) or the sp (receiver) have a provisioning system 
>> to do this. 
>>  
>> The solution and the simplicity depends on where the control needs to be. 
>> 
>> Phil
>> 
>> On Apr 5, 2016, at 18:59, Hardt, Dick  wrote:
>> 
>> Use case: An admin for an organization would like to enable her users to 
>> access a SaaS application at her IdP. 
>>  
>> User experience: 
>>  • Admin authenticates to IdP in browser
>>  • Admin selects SaaS app to federate with from list at IdP
>>  • IdP optionally presents config options
>>  • IdP redirects Admin to SaaS app
>>  • Admin authenticates to SaaS app
>>  • SaaS app optionally gathers config options
>>  • SaaS app redirects admin to IdP
>>  • IdP confirms successful federation => OIDC / SAML and SCIM are now 
>> configured and working between IdP and SaaS App
>> Who else is interested in solving this?
>>  
>> Is there interest in working on this in either SCIM or OAUTH Wgs?
>>  
>> Any one in BA interested in meeting on this topic this week?
>>  
>> — Dick
>> ___
>> scim mailing list
>> s...@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>> ___
>> 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

-- Roland
"Education is the path from cocky ignorance to miserable uncertainty.” - Mark 
Twain



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

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Roland Hedberg]

I support this document being moved forward with these two changes:

- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as 
proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of 
’openid-configuration’ as proposed by Justin.

> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig :
> 
> Hi all,
> 
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> 
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
> 
> Please have your comments in no later than March 10th.
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

— Roland

”Everybody should be quiet near a little stream and listen."
From ’Open House for Butterflies’ by Ruth Krauss



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Roland Hedberg]

+1 

> 29 feb. 2016 kl. 15:41 skrev Brian Campbell :
> 
> +1 
> 
> On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov  > wrote:
> +1
> 
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in the 
> > right direction. It does, however, still have too many vestiges of its 
> > OpenID Connect origins. One issue in particular still really bothers me: 
> > the use of “/.well-known/openid-configuration” in the discovery portion. Is 
> > this an OAuth discovery document, or an OpenID Connect one? There is 
> > absolutely no compelling reason to tie the URL to the OIDC discovery 
> > mechanism.
> >
> > I propose that we use “/.well-known/oauth-authorization-server” as the 
> > default discovery location, and state that the document MAY also be 
> > reachable from “/.well-known/openid-configuration” if the server also 
> > provides OpenID Connect on the same domain. Other applications SHOULD use 
> > the same parameter names to describe OAuth endpoints and functions inside 
> > their service-specific discovery document.
> >
> >  — Justin
> > ___
> > 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

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

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[Roland Hedberg]

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley :
> 
> +1 to adopt this draft.
> 
>> On Feb 12, 2016, at 3:07 AM, Mike Jones  wrote:
>> 
>> Draft -05 incorporates the feedback described below - deleting the request 
>> parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for 
>> authentication without employing appropriate extensions, and no longer 
>> requiring a specification for IANA registration.  I believe that it’s now 
>> ready for working group adoption.
>> 
>>   -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for 
>> Adoption Finalized
>> 
>> Hi all,
>> 
>> On January 19th I posted a call for adoption of the Authentication Method 
>> Reference Values specification, see 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>> 
>> What surprised us is that this work is conceptually very simple: we define 
>> new claims and create a registry with new values. Not a big deal but that's 
>> not what the feedback from the Yokohama IETF meeting and the subsequent call 
>> for adoption on the list shows. The feedback lead to mixed feelings and it 
>> is a bit difficult for Derek and myself to judge consensus.
>> 
>> Let me tell you what we see from the comments on the list.
>> 
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James 
>> Manger asks for significant changes. Among other things, he wants to remove 
>> one of the claims. He provides a detailed review and actionable items.
>> 
>> William Denniss believes the document is ready for adoption but agrees with 
>> some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>> 
>> Justin is certainly the reviewer with the strongest opinion. Here is one of 
>> his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>> 
>> Among all concerns Justin expressed the following one is actually actionable 
>> IMHO: Justin is worried that reporting how a person authenticated to an 
>> authorization endpoint and encouraging people to use OAuth for 
>> authentication is a fine line. He believes that this document leads readers 
>> to believe the latter.
>> 
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we 
>> need to make sure that people are not mislead about the intention of the 
>> document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, methods 
>> listed are really not useful,
>> 
>> Phil agrees with the document adoption but has some remarks about the 
>> registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>> 
>> With my co-chair hat on: I just wanted to clarify that registering claims 
>> (and values within those claims) is within the scope of the OAuth working 
>> group. We standardized the JWT in this group and we are also chartered to 
>> standardize claims, as we are currently doing with various drafts. Not 
>> standardizing JWT in the IETF would have lead to reduced interoperability 
>> and less security. I have no doubts that was a wrong decision.
>> 
>> In its current form, there is not enough support to have this document as a 
>> WG item.
>> 
>> We believe that the document authors should address some of the easier 
>> comments and submit a new version. This would allow us to reach out to those 
>> who had expressed concerns about the scope of the document to re-evaluate 
>> their decision. A new draft version should at least address the following 
>> issues:
>> 
>> * Clarify that this document is not an encouragement for using OAuth as an 
>> authentication protocol. I believe that this would address some of the 
>> concerns raised by Justin and John.
>> 
>> * Change the registry policy, which would address one of the comments from 
>> James, William, and Phil.
>> 
>> Various other items require discussion since they are more difficult to 
>> address. For example, John noted that he does not like the use of request 
>> parameters. Unfortunately, no alternative is offered. I urge John to provide 
>> an alternative proposal, if there is one. Also, the remark that the values 
>> are meaningless could be countered with an alternative proposal. James 
>> wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>> 
>> After these items have been addressed we believe that more folks in the 
>> group will support the document.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> 
>> 
>> 

Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

[Roland Hedberg]

+1

> 6 feb 2016 kl. 19:56 skrev William Denniss :
> 
> +1 to adopt.
> 
> I don't think we're planning to use this, but it looks useful and doesn't 
> harm interoperability so I support it.
> 
> On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt  
> wrote:
> +1
> 
> 
> Am 04.02.2016 um 17:37 schrieb John Bradley:
> I support it.
> 
> I have always thought of this as informational.  It is not the only way to do 
> it, and has no real interoperability impact.
> 
> John B.
> On Feb 4, 2016, at 3:29 AM, Mike Jones  wrote:
> 
> I support adoption of this document by the working group as either an 
> experimental or information specification.
> 
> -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 19, 2016 4:05 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2
> 
> Hi all,
> 
> this is the call for adoption of Stateless Client Identifier for OAuth 2, see
> https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02
> 
> Please let us know by Feb 2nd whether you accept / object to the adoption of 
> this document as a starting point for work in the OAuth working group.
> 
> 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
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

”Everybody should be quiet near a little stream and listen."
From ’Open House for Butterflies’ by Ruth Krauss



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

[Roland Hedberg]

+1

> 20 jan 2016 kl. 23:07 skrev John Bradley :
> 
> So if this is scoped to be a registry for the values of a JWT claim then it 
> is fine.
> We should discourage people from thinking that it is part of the OAuth 
> protocol vs JWT claims.
> 
> John B.
> 
>> On Jan 20, 2016, at 6:29 PM, Mike Jones  wrote:
>> 
>> The primary purpose of the specification is to establish a registry for 
>> "amr" JWT claim values.  This is important, as it increases interoperability 
>> among implementations using this claim.
>> 
>> It's a fair question whether "requested_amr" should be kept or dropped.  I 
>> agree with John and James that it's bad architecture.  I put it in the -00 
>> individual draft to document existing practice.  I suspect that should the 
>> draft is adopted by the working group as a starting point, one of the first 
>> things the working group will want to decide is whether to drop it.  I 
>> suspect that I know how this will come out and I won't be sad, 
>> architecturally, to see it go.
>> 
>> As to whether this belongs in the OAuth working group, long ago it was 
>> decided that JWT and JWT claim definitions were within scope of the OAuth 
>> working group.  That ship has long ago sailed, both in terms of RFC 7519 and 
>> it continues to sail, for instance, in draft-ietf-oauth-proof-of-possession, 
>> which defines a new JWT claim, and is in the RFC Editor Queue.  Defining a 
>> registry for values of the "amr" claim, which is registered in the 
>> OAuth-established registry at http://www.iana.org/assignments/jwt, is 
>> squarely within the OAuth WG's mission for the creation and stewardship of 
>> JWT.
>> 
>>  -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
>> Sent: Wednesday, January 20, 2016 12:44 PM
>> To: Justin Richer 
>> Cc:  
>> Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference 
>> Values
>> 
>> I see your point that it is a fine line reporting how a person authenticated 
>> to a Authorization endpoit (it might be by SAML etc) and encouraging people 
>> to use OAuth for Authentication.
>> 
>> We already have the amr response in connect.  The only thing really missing 
>> is a registry.  Unless this is a sneaky way to get requested_amr into 
>> Connect?
>> 
>> John B.
>>> On Jan 20, 2016, at 5:37 PM, Justin Richer  wrote:
>>> 
>>> Just reiterating my stance that this document detailing user authentication 
>>> methods has no place in the OAuth working group.
>>> 
>>> — Justin
>>> 
 On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig  
 wrote:
 
 Hi all,
 
 this is the call for adoption of Authentication Method Reference
 Values, see
 https://tools.ietf.org/html/draft-jones-oauth-amr-values-03
 
 Please let us know by Feb 2nd whether you accept / object to the
 adoption of this document as a starting point for work in the OAuth
 working group.
 
 Note: The feedback during the Yokohama meeting was inconclusive,
 namely
 9 for / zero against / 6 persons need more information.
 
 You feedback will therefore be important to find out whether we
 should do this work in the OAuth working group.
 
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

[Roland Hedberg]

+1

> 4 feb 2016 kl. 08:10 skrev Phil Hunt :
> 
> +1 for adoption.
> 
> However I would like a rel value distinct from OpenID (see separate email). 
> While the mechanics of discovery is the same, I believe some clients will 
> want to distinguish between OAuth AS’s and OIDC OPs.  Further, I would expect 
> over time that different discovery features may be required. Locking them 
> together seems like a pre-mature or rush choice.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> 
> 
>> On Feb 3, 2016, at 10:44 PM, William Denniss  wrote:
>> 
>> +1 for adoption of this document by the working group
>> 
>> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones  
>> wrote:
>> I support adoption of this document by the working group.  I'll note that 
>> elements of this specification are already in production use by multiple 
>> parties.
>> 
>> -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Tuesday, January 19, 2016 3:49 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
>> 
>> Hi all,
>> 
>> this is the call for adoption of OAuth 2.0 Discovery, see
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00
>> 
>> Please let us know by Feb 2nd whether you accept / object to the adoption of 
>> this document as a starting point for work in the OAuth working group.
>> 
>> Note: If you already stated your opinion at the IETF meeting in Yokohama 
>> then you don't need to re-state your opinion, if you want.
>> 
>> The feedback at the Yokohama IETF meeting was the following: 19 for / zero 
>> against / 4 persons need more information.
>> 
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

[Roland Hedberg]

+1

> 4 feb 2016 kl. 07:25 skrev Mike Jones :
> 
> I support adoption of this document by the working group.
> 
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 19, 2016 3:48 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open 
> Redirector
> 
> Hi all,
> 
> this is the call for adoption of OAuth 2.0 Security: OAuth Open Redirector, 
> see
> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02
> 
> Please let us know by Feb 2nd whether you accept / object to the adoption of 
> this document as a starting point for work in the OAuth working group.
> 
> Note: At the IETF Yokohama we asked for generic feedback about doing security 
> work in the OAuth working group and there was very positive feedback. 
> However, for the adoption call we need to ask for individual documents. 
> Hence, you need to state your view again.
> 
> Ciao
> Hannes & Derek
> 
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow

[Roland Hedberg]

+1

> 4 feb 2016 kl. 07:26 skrev Mike Jones :
> 
> I support adoption of this document by the working group.
> 
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 19, 2016 3:48 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow
> 
> Hi all,
> 
> this is the call for adoption of OAuth 2.0 Device Flow, see
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
> 
> Please let us know by Feb 2nd whether you accept / object to the adoption of 
> this document as a starting point for work in the OAuth working group.
> 
> Note: If you already stated your opinion at the IETF meeting in Yokohama then 
> you don't need to re-state your opinion, if you want.
> 
> The feedback at the Yokohama IETF meeting was the following: 16 persons for 
> doing the work / 0 persons against / 2 persons need more info
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

[Roland Hedberg]

> 3 feb 2016 kl. 00:48 skrev Phil Hunt :
> 
> 
> Item 2:  rel value for webfinger
> It seems to me while the discovery requirements for plain OAuth and OIDC are 
> the same for today that might not always be true.  What will happen if OIDC 
> wants to add more stuff?  Will plain oAuth sites have to comply?
> 
> A client may want to know both the OAuth discovery endpoint information for a 
> resource AND it might want to know the OIDC discovery information.  They 
> endpoints might not always be the same - how do we tell them apart?

I’ve (we’ve) had exactly this problem in the UMA use-case.
Which is just one example where an AS may have OAuth2 or OIDC parentage.
So, I support having different real values.

— Roland



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PKCE & Hybrid Flow

[Roland Hedberg]

> 27 jan. 2016 kl. 13:51 skrev John Bradley :
> 
> It is confusing that the value is a string that is order independent based on 
> space breaks, rather than a space separated list of responses requested.

Absolutely, I’ve always found that completely broken.

> Changing it now may be more trouble than it is worth, if it may break 
> deployments.   The editor at the time really didn’t want multiple response 
> types, so that was a way to have them but not really.
> 
> John B.
> 
>> On Jan 26, 2016, at 11:11 PM, Nat Sakimura > > wrote:
>> 
>> To the end, perhaps amending RFC6749 so that the response type is treated as 
>> a space separated value would be a better way to go? 
>> 
>> 2016年1月27日(水) 5:20 John Bradley > >:
>> Yes it also applies to the “code id_token” response_type.   It would also 
>> apply to “code token” , “code token id_token” response types as well though 
>> I can’t think of why a native app would use those.
>> 
>> We can look at a errata to clarify.  It is a artifact of resonse_type being 
>> treated as a single string as opposed to being space separated values as 
>> most people would expect.
>> 
>> John B.
>> 
>>> On Jan 26, 2016, at 5:11 PM, Dominick Baier >> > wrote:
>>> 
>>> Hi, 
>>> 
>>> PKCE only mentions OAuth 2.0 code flow - but wouldn’t that also apply to 
>>> OIDC hybrid flow e.g. code id_token?
>>> 
>>> — 
>>> cheers
>>> Dominick Baier
>>> 
>>> ___
>>> 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

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

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

[Roland Hedberg]

+1  :-)

> 22 jan 2016 kl. 20:05 skrev George Fletcher :
> 
> Isn't that your department Paul? I have high expectations!
> 
> On 1/22/16 2:00 PM, Paul Madsen wrote:
>> tshirt or it didnt happen
>> 
>> On 1/22/16 1:57 PM, John Bradley wrote:
>>> Now that we have a cool name all we need is a logo for the attack and per 
>>> haps an anime character, and we are done with all the hard work:)
>>> 
>>> John B.
 On Jan 22, 2016, at 2:54 PM, David Waite  
 wrote:
 
 It’s pronounced FronkenSTEEN-ian.
 
 -DW
 
> On Jan 22, 2016, at 10:02 AM, George Fletcher  wrote:
> 
> "Frankensteinian Amalgamation" -- David Waite
> 
> I like it! :)
> 
> On 1/22/16 8:11 AM, William Denniss wrote:
>> +1 ;)
>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley  wrote:
>> Perhaps Frankenstein response is a better name than cut and paste attack.
>> 
>> John B.
>> 
>> On Jan 22, 2016 1:22 AM, "David Waite"  
>> wrote:
>>> On Jan 21, 2016, at 2:50 PM, John Bradley  wrote:
>>> 
>>> In that case you probably would put a hash of the state in the code to 
>>> manage size.  The alg would be up to the AS, as long as it used the 
>>> same hash both places it would work.
>> Yes, true.
>>> 
>>> Sending the state to the token endpoint is like having nonce and c_hash 
>>> in the id_token, it binds the issued code to the browser instance.
>> I think I understand what you are saying. Someone won’t be able to 
>> frankenstein up a state and a token from two different responses from an 
>> AS, and have a client successfully fetch an access token based on the 
>> amalgamation.
>> 
>>> This protects against codes that leak via redirect uri pattern 
>>> matching. failures etc.  It prevents an attacker from being able to 
>>> replay a code from a different browser.
>> Yes, if a party intercepts the redirect_url, or the AS fails to enforce 
>> one time use (which even for a compliant implementation could just mean 
>> the attacker was faster than the state propagated within the AS)
>> 
>> Makes sense. Thanks John.
>> 
>> -DW
>> 
>>> If the client implements the other mitigations on the authorization 
>>> endpoint, then it wouldn't be leaking the code via the token endpoint.
>>> 
>>> The two mitigations are for different attacks, however some of the 
>>> attacks combined both vulnerabilities.
>>> 
>>> Sending the iss and client_id is enough to stop the confused client 
>>> attacks, but sending state on its own would not have stopped all of 
>>> them.
>>> 
>>> We discussed having them in separate drafts, and may still do that.   
>>> However for discussion having them in one document is I think better in 
>>> the short run.
>>> 
>>> John B.
>>> 
 On Jan 21, 2016, at 4:48 PM, David Waite 
  wrote:
 
 Question:
 
 I understand how “iss" helps mitigate this attack (client knows 
 response was from the appropriate issuer and not an attack where the 
 request was answered by another issuer).
 
 However, how does passing “state” on the authorization_code grant 
 token request help once you have the above in place? Is this against 
 some alternate flow of this attack I don’t see, or is it meant to 
 mitigate some entirely separate attack?
 
 If one is attempting to work statelessly (e.g. your “state” parameter 
 is actual state and not just a randomly generated value), a client 
 would have always needed some way to differentiate which issuer the 
 authorization_code 
   grant token request would be sent to.
 
 However, if an AS was treating “code” as a token (for instance, 
 encoding: client, user, consent time and approved  
  scopes), the AS now has to 
 include the client’s state as well. This would effectively double 
 (likely more with encoding) the state sent in the authorization 
 response back to the client redirect URL, adding more pressure against 
 maximum URL sizes.
 
 -DW
>> ___
>> 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
> 
> --
> Chief Architect
> Identity Services Engineering Work:
> george.fletc...@teamaol.com

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Roland Hedberg]

+1 for adoption

> 21 jan 2016 kl. 07:14 skrev Antonio Sanso :
> 
> +1 for adoption
> On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig  
> wrote:
> 
>> Hi all,
>> 
>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>> 
>> Please let us know by Feb 9th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Note: This call is related to the announcement made on the list earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>> time for analysis is provided due to the complexity of the topic.
>> 
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

[Roland Hedberg]

+1 for adoption

> 21 jan 2016 kl. 07:11 skrev William Denniss :
> 
> I believe this is important work.
> 
> The original OAuth 2 spec left the topic of native apps largely undefined 
> which is fair enough, the mobile-first revolution had yet to really take hold 
> and people didn't have much implementation experience for OAuth on mobile. 
> But we've come a long way since then, we have the experience now and I think 
> there is a need for leadership in this space, and that it makes sense for the 
> OAUTH-WG to continue our work and provide that leadership.
> 
> The risk of not defining a best practice for native apps is dilution of the 
> open standards – if everyone implements OAuth differently for native apps, 
> and RPs have to write IDP-specific code then what is the point of having 
> OAuth as a standard in the first place? Security is a major concern as well, 
> there are a lot of ways to mess this up and the security situation for OAuth 
> in many native apps is not nearly as good as it could be.
> 
> By providing leadership in the form of a working group document, we can 
> present community advice with the hope that IDPs and RPs alike will follow 
> our recommendations, resulting in more interoperability, better usability and 
> higher security.
> 
> The best part about this spec is that it's pure OAuth! Just wrapped with some 
> native app specific recommendations for both RPs and IDPs, to achieve the 
> desired levels of usability and security on mobile.
> 
> I will point out that we have rough consensus and running code. The rough 
> consensus can be seen from the WG votes, and the sentiment on this thread 
> (your dissenting opinion notwithstanding). Regarding running code, my team is 
> in the process of open sourcing libraries that will implement this best 
> practice to the letter (and the code's already running, I assure you). The 
> proprietary Google Sign-in and Facebook Sign-in SDKs are also using in-app 
> browser tabs for OAuth flows in production today, which I think is further 
> evidence that this is a viable pattern.
> 
> This document and proposal was never part of the OpenID working group that 
> you refer to below.
> 
> I'm not saying the document is perfect, and it is definitely in need of an 
> update! But I'm committed to listening to the community and taking it 
> forward. Now that the dependencies have launched, and our library 
> implementations are done, I plan to update the doc with the feedback from 
> this community, and the lessons we and others have learnt from our 
> implementations.
> 
> I hope the working group will consider adopting this document.
> 
> Kind Regards,
> William
> 
> 
> On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin  
> wrote:
> This work had many issues in the OpenID WG where it failed why should this be 
> a WG item here ? The does meet the requirements for experimental, there is a 
> fine line between informational and experimental, I would be OK with either 
> but prefer experimental, I don’t think that this should become a standard.
> 
> 
> 
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, January 20, 2016 12:11 PM
> To: Nat Sakimura 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps
> 
> 
> 
> PS as you probably suspected I am in favour of moving this forward.
> 
> 
> 
> 
> 
> On Jan 20, 2016, at 5:08 PM, Nat Sakimura  wrote:
> 
> 
> 
> +1 for moving this forward.
> 
> 2016年1月21日木曜日、John Bradleyさんは書きました:
> 
> Yes more is needed.   It was theoretical at that point.  Now we have 
> implementation experience.
> 
> 
> 
> On Jan 20, 2016, at 3:38 PM, Brian Campbell  
> wrote:
> 
> 
> 
> There is 
> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A 
> which has some mention of SFSafariViewController and Chrome Custom Tabs.
> 
> Maybe more is needed?
> 
> 
> 
> On Wed, Jan 20, 2016 at 10:45 AM, John Bradley  wrote:
> 
> Yes, in July we recommended using the system browser rather than WebViews.
> 
> 
> 
> About that time Apple announced Safari view controller and Google Chrome 
> custom tabs.   The code in the OS is now stable and we have done a fair 
> amount of testing.
> 
> 
> 
> The OIDF will shortly be publishing reference libraries for iOS and Android 
> to how how to best use View Controllers, and PKCE in native apps on those 
> platforms.
> 
> 
> 
> We do need to update this doc to reflect what we have learned in the last 6 
> months.
> 
> 
> 
> One problem we do still have is not having someone with Win 10 mobile 
> experience to help document the best practices for that platform.
> 
> I don’t understand that platform well enough yet to include anything.
> 
> 
> 
> John B.
> 
> 
> 
> On Jan 20, 2016, at 12:40 PM, Aaron Parecki  wrote:
> 
> 
> 
> The section on 

Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

[Roland Hedberg]

And I agree with Phil’s agreement with Brian :-)

I should also add that I during the last part of the meeting and on my flight 
home afterwards implemented the techniques I felt we had come to an agreement 
on at the meeting. That is the new authorization request response parameters 
iss and client_id as well as the use of state_hash at the token endpoint.

> 13 jan 2016 kl. 05:31 skrev Phil Hunt (IDM) :
> 
> I am in agreement with Brian.
> 
> I understand what Mike is trying to do is safer, but I too am concerned that 
> the escalation in knowledge/skills for oauth clients is significant.
> 
> This may not be the same concern as for OIDC where we can expect more 
> sophistication.
> 
> Phil
> 
> On Jan 12, 2016, at 20:03, Justin Richer  wrote:
> 
>> +1 to Brian’s point, and points to Mike for promising to address this. I 
>> wasn’t able to attend the meeting in Darmstadt, but I’ve been following the 
>> discussion and original papers. Let’s take this one piece at a time and not 
>> overreach with a solution.
>> 
>> In particular, the whole “late binding discovery” bit would cause huge 
>> problems on its own. There’s good reason that OpenID Connect mandates that 
>> the “iss” value returned from the discovery endpoint MUST be the same as the 
>> “iss” value coming back from the ID Token, so let’s not ignore that.
>> 
>>  — Justin
>> 
>>> On Jan 12, 2016, at 5:53 PM, Mike Jones  wrote:
>>> 
>>> John Bradley and I went over this today and I'm already planning on 
>>> simplifying the draft along the lines described. I would have written this 
>>> earlier but I've been busy at a NIST meeting today.
>>> 
>>> John has also stated writing a note about how cut-and-paste does and 
>>> doesn't apply here but hasn't finished it yet because he's been similarly 
>>> occupied.  He's also started writing up the state_hash token request 
>>> parameter, as he agreed to do.
>>> 
>>> Watch this space for the new draft...
>>> 
>>> Best wishes,
>>> -- Mike
>>> From: Brian Campbell
>>> Sent: ‎1/‎12/‎2016 5:24 PM
>>> To: oauth
>>> Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
>>> 
>>> The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on 
>>> them) take advantage of the fact that there's nothing in the OAuth 
>>> authorization response to the client's redirect_uri that identifies the 
>>> authorization server. As a result, a variety of techniques can be used to 
>>> trick the client into sending the code (or token in some cases) to the 
>>> wrong endpoint.
>>> 
>>> To the best of my recollection the general consensus coming out of the 
>>> meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: 
>>> Authorization Server Mix-Up) was to put forth an I-D as a simple extension 
>>> to OAuth, which described how to return an issuer identifier for the 
>>> authorization server and client identifier as authorization response 
>>> parameters from the authorization endpoint. Doing so enables the client to 
>>> know which AS the response came from and thus avoid sending the code to a 
>>> different AS. Also, it doesn't introduce application/message level 
>>> cryptography requirements on client implementations.
>>> 
>>> The mitigation draft that was posted yesterday diverges considerably from 
>>> that with a significantly expanded scope that introduces OpenID Connect ID 
>>> Tokens (sort of anyway) to regular OAuth and the retrieval of a 
>>> metadata/discovery document in-between the authorization request and the 
>>> access token request.
>>> 
>>> It is possible that my recollection from Darmstadt is wrong. But I expect 
>>> others who were there could corroborate my account of what transpired. Of 
>>> course, the agreements out of the Darmstadt meeting were never intended to 
>>> be the final word - the whole WG would have the opportunity to weigh, as is 
>>> now the case. However, a goal of meeting face-to-face was to come away with 
>>> a good consensus towards a proposed solution that could (hopefully) be 
>>> implementable in the very near term and move thought the IETF process in an 
>>> expedited manner. I believe we'd reached consensus but the content of -00 
>>> draft does not reflect it.
>>> 
>>> I've made the plea off-list several times to simplify the draft to reflect 
>>> the simple solution and now I'm doing the same on-list. Simplify the 
>>> response validation to just say not to send the code/token back to an AS 
>>> entity other that the one identified by the 'iss' in the response. And 
>>> remove the id_token and JWT parts that .
>>> 
>>> If this WG and/or the larger community believes that OAuth needs signed 
>>> responses, let's develop a proper singed response mechanism. I don't know 
>>> if it's needed or not but I do know that it's a decent chunk of work that 
>>> should be conscientiously undertaken independent of what can and should be 
>>> a simple to understand and implement fix for the idp 

Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

[Roland Hedberg]

As an implementor like Justin, I see no problem with changing expires_at and 
issued_at to the values proposed below.
It's a minor code change and I don't have a large deployment to deal with.

I also agree with Justin and Phil about token_endpoint_auth_method.

22 maj 2013 kl. 20:34 skrev Phil Hunt phil.h...@oracle.com:

 +1
 
 I also agree with Justin's comment on token_endpoint_auth_method. 
 Never-the-less, I did want to pass along the feedback that some were confused.
 
 The expires_at, issued_at thing though is particularly confusing (though the 
 text may be clear) and is a higher priority issue in my opinion.
 
 Phil
 
 @independentid
 www.independentid.com
 phil.h...@oracle.com
 
 
 
 
 
 On 2013-05-22, at 11:19 AM, Justin Richer wrote:
 
 Speaking as an implementor, I'm actually in favor of changing expires_at 
 and issued_at to the values proposed below. It would require some minor 
 code changes on my end, but the impact would be minimal, and I think that 
 the new names are *much* more clear to new developers. I think it will save 
 us a lot of questions and headaches going forward. I believe that changing 
 it now will have minimal impact on any deployed and running code (there are 
 no large-scale services that I am aware of), and it will make things 
 clearer. So I vote for B for #1 and #2.
 
 I believe token_endpoint_auth_method is sufficient as is, since the client 
 is the only thing that authenticates to the token endpoint. 
 
 
 [[ Note: As an editor, I don't believe it's really in my power to make that 
 change unless there's support in the working group for making it. I really 
 want more feedback from people, with explanation if you can. ]]
 
  -- Justin
 
 
 On 05/20/2013 11:09 AM, Justin Richer wrote:
 Phil Hunt's review of the Dynamic Registration specification has raised a 
 couple of issues that I felt were getting buried by the larger discussion 
 (which I still strongly encourage others to jump in to). Namely, Phil has 
 suggested a couple of syntax changes to the names of several parameters. 
 
 
 1) expires_at - client_secret_expires_at
 2) issued_at - client_id_issued_at
 3) token_endpoint_auth_method - token_endpoint_client_auth_method
 
 
 I'd like to get a feeling, especially from developers who have deployed 
 this draft spec, what we ought to do for each of these:
 
  A) Keep the parameter names as-is
  B) Adopt the new names as above
  C) Adopt a new name that I will specify
 
 In all cases, clarifying text will be added to the parameter *definitions* 
 so that it's more clear to people reading the spec   what each piece 
 does. Speaking as the editor: A is the default as far as I'm concerned, 
 since we shouldn't change syntax without very good reason to do so. That 
 said, if it's going to be better for developers with the new parameter 
 names, I am open to fixing them now.
 
 Naming things is hard.
 
  -- Justin
 
 
 ___
 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

-- Roland
Education is the path from cocky ignorance to miserable uncertainty.” - Mark 
Twain




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

Re: [OAUTH-WG] [jose] Dominick Baier's JWT implementation

[Roland Hedberg]

27 maj 2012 kl. 22:32 skrev Leif Johansson:

 On that topic: what is the most current/complete implementation for python?

I did a search half a year ago for JWT implementations in Python.
Found two: PyJWT by Jeff Lindsay and jwt-python by Andrew Ekstedt.

I used parts from both of them and did my own version.
It's part of my OpenID Connect implementation.

-- Roland
--
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS) 
Umeå University 
SE-901 87 Umeå, Sweden  
Phone +46 90 786 68 44
Mobile +46 70 696 68 44 
www.its.umu.se 

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