Re: [OAUTH-WG] Call for Adoption: DPoP

[Anthony Nadalin]

+1

From: OAuth  On Behalf Of Mike Jones
Sent: Tuesday, March 17, 2020 8:14 AM
To: Rifaat Shekh-Yusef ; oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] Call for Adoption: DPoP

I am for adoption of DPoP.

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Tuesday, March 17, 2020 5:21 AM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Call for Adoption: DPoP

All,

As per the conclusion of the PoP interim meeting, this is a call for adoption 
for the OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer 
(DPoP) document:
https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/

Please, let us know if you support or object to the adoption of this document 
as a working group document by March 31st.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant

[Anthony Nadalin]

I would suggest a SHOULD NOT instead of MUST, there are still sites using this 
and a grace period should be provided before a MUST is pushed out as there are 
valid use cases out there still.

From: OAuth  On Behalf Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.org
Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant

Hey List

(Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, 
Torsten, and I are working on)

In the security topics doc

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4

The password grant MUST not be used.

Some background for those interested. I added this grant into OAuth 2.0 to 
allow applications that had been provided password to migrate. Even with the 
caveats in OAuth 2.0, implementors decide they want to prompt the user to enter 
their credentials, the anti-pattern OAuth was created to eliminate.


Does anyone have concerns with dropping the password grant from the OAuth 2.1 
document so that developers don't use it?

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

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Anthony Nadalin]

I know you were too polite !

From: Steinar Noem 
Sent: Saturday, August 10, 2019 11:04 AM
To: Nat Sakimura 
Cc: Anthony Nadalin ; Mike Jones 
; OAuth WG 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

That is good to hear, Nat.
I tried to be as polite as possible in my response.

lør. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura 
mailto:sakim...@gmail.com>>:
I think Tony was just joking as it was quite a hassle for both of us to get to 
Gjøvik for an ISO meeting.

On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
Hey Anthony. Gjøvik is part of NTNU, we are waiting for feedback from them :)

I think Trondheim is more accessible (travel time) and has more to offer.

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin 
mailto:40microsoft@dmarc.ietf.org>>:
How about the University in Gjovik ?
Get Outlook for Android<https://aka.ms/ghei36>


From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Daniel Fett mailto:danielf%2boa...@yes.com>>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>; 
dba...@leastprivilege.com<mailto:dba...@leastprivilege.com> 
mailto:dba...@leastprivilege.com>>
Cc: Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>;
 OAuth WG mailto:oauth@ietf.org>>

Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

Not yet, we are talking to potential venues. It's vacation time in Norway right 
now, so that will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
August will conflict with holiday time for most Europeans…

Just been to Trondheim last week - it was lovely weather.

———
Dominick


On 25. July 2019 at 22:14:28, Mike Jones 
(michael.jones=40microsoft@dmarc.ietf.org<mailto:michael.jones=40microsoft@dmarc.ietf.org>)
 wrote:
I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-Original Message-
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll be 
easier/cheaper to bundle the two trips into one. (Hopefully we could get the 
OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
> mailto:danielf%2boa...@yes.com>> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Security 
>> Workshop in Trondheim, Norway. We will therefore start with the planning.
>>
>> After checking various event calendars it seems like the following dates are 
>> suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The 
>> latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/security 
>> events we will pick one of these dates in the next two weeks or so
>>
>> -Daniel
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org<mailto:OAuth@ietf.org>
>> https://www
>> .ietf.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org&data=02%7C01%7Ctonynad%40microsoft.com%7C24500550fdb347a700f808d71dbd3661%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637010570831332090&sdata=DdWZCoppTjVZTdtgt%2FER7N59HHmcKEslU8zJYwCBz0Q%3D&reserved=0>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon
>> es%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Ctonynad%40microsoft.com%7C24500550fdb347a700f808d71dbd3661%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637010570831342083&sdata=QwDmcdAgVzCSD2jWgLgbc%2BpPMld3dVwoGUyuk5HlfT4%3D&reserved=0>%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Anthony Nadalin]

How about the University in Gjovik ?

Get Outlook for Android


From: OAuth  on behalf of Daniel Fett 

Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt ; dba...@leastprivilege.com 

Cc: Mike Jones ; OAuth WG 

Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

Not yet, we are talking to potential venues. It's vacation time in Norway right 
now, so that will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
August will conflict with holiday time for most Europeans…

Just been to Trondheim last week - it was lovely weather.

———
Dominick


On 25. July 2019 at 22:14:28, Mike Jones 
(michael.jones=40microsoft@dmarc.ietf.org)
 wrote:

I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-Original Message-
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll be 
easier/cheaper to bundle the two trips into one. (Hopefully we could get the 
OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
> mailto:danielf%2boa...@yes.com>> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Security 
>> Workshop in Trondheim, Norway. We will therefore start with the planning..
>>
>> After checking various event calendars it seems like the following dates are 
>> suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The 
>> latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/security 
>> events we will pick one of these dates in the next two weeks or so.
>>
>> -Daniel
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones
> %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0

___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Anthony Nadalin]

I support adoption of this draft as a working group document with the following 
caveats:

1. These are not to be used as ID Tokens/authentication tokens 
2. The privacy issues must be addressed 
3. Needs to be extensible, much like ID-Token, can't be 100% fixed 


-Original Message-
From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  
document following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=0

Please let us know by April 22nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&reserved=0

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

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Anthony Nadalin]

I’m concerned over the security implications of a client being able to 
introspect a token, for bearer tokens this can be very problematic, so unless 
the issues with possible token theft can be addressed I don’t support this as a 
WG draft

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 10:44 AM
To: oauth 
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token 
Introspection"

Hi all,

This is the call for adoption of the 'JWT Response for OAuth Token 
Introspection' document following the presentation by Torsten at the Montreal 
IETF meeting where we didn't have a chance to do a call for adoption in the 
meeting itself.

Here is presentation by Torsten:
https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01

Please let us know by August 2nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

[Anthony Nadalin]

I was dialed in and no one was there

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, June 18, 2018 2:06 PM
To: Brian Campbell 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

Rifaat was on the call for 30mins but nobody joined. I couldn’t make it due to 
a delayed flight.

Write-ups are in progress.

Ciao
Hannes


From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: 18 June 2018 18:47
To: Hannes Tschofenig
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

I tried to join this morning but was the only one on the webex (of course, user 
error could be involved on my part).

I didn't have much specific for the call but did want to politely ask the 
Chairs how the document shepherding was coming along for 
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
 ?



On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

Rifaat and I will again dial into the Webex next Monday to hear whether someone 
of you has anything to discuss/report/suggest/….

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Exchange - IPR Disclosure

[Anthony Nadalin]

I am not aware of any IPR on the token exchange document.


From: Rifaat Shekh-Yusef [mailto:rifaat.i...@gmail.com]
Sent: Thursday, November 23, 2017 8:14 AM
To: draft-ietf-oauth-token-exchange@ietf.org; oauth 
Cc: Hannes Tschofenig 
Subject: Token Exchange - IPR Disclosure

Authors,

As part of the write-up for the Token Exchange document, we need an IPR 
disclosure from all of you.

Are you aware of any IPR related to the following Token Exchange document?
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

Regards,
 Rifaat

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

Re: [OAUTH-WG] Token Binding Presentations?

[Anthony Nadalin]

I'm unaware of any support for "OAuth" Token Binding from Microsoft, so I 
assume you are talking just about Token Binding cookies

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Friday, March 17, 2017 10:43 AM
To: Jim Manico 
Cc: IETF OAUTH 
Subject: Re: [OAUTH-WG] Token Binding Presentations?

This has some of the basic info, but needs some updating.   
http://www.browserauth.net/

Other than that there are the specs in the Token binding WG and the one we just 
updated for OAuth.

With Microsoft supporting it in RS2 coming out in a month or so I would hope to 
see some developer documentation from them soon.

John B.

On Mar 17, 2017, at 12:09 PM, Jim Manico 
mailto:j...@manicode.com>> wrote:

Hello OAuthers,

I'm trying to get my head around token binding beyond the RFC. Are there any 
presentations or other media on token binding that any of you are aware of? My 
google-fu is coming up empty.

Thanks and Aloha,
- Jim
___
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] Updated Shepherd Write-Up for Native Apps document

[Anthony Nadalin]

I'm still getting feedback on the Windows examples that are pointed to by the 
spec, since it's not a simple case on Windows 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, March 6, 2017 8:00 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

Here is the shepherd write-up:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhannestschofenig%2Ftschofenig-ids%2Fblob%2Fmaster%2Fshepherd-writeups%2FWriteup_OAuth_NativeApps.txt&data=02%7C01%7Ctonynad%40microsoft.com%7C9a9ec9f090c74e34fb1a08d464a9e0a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244128165469063&sdata=olsSc81lMAqvlfAEBPCXY9CkIGv88W2Pt%2BkGj8yT2aY%3D&reserved=0

Feedback appreciated. I will also do another shepherd review.

Ciao
Hannes

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

[Anthony Nadalin]

Not true John, the CTAP support that is current would support the web-view w/o 
any changes 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Monday, March 6, 2017 12:16 PM
To: Hannes Tschofenig 
Cc: internet-dra...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

On fido I can tell you that for security reasons U2F wont work from a web-view 
currently.

Once we move to Web Auth (Fido 2) where the OS provides a API for apps to call 
to get the token it will work but the tokens are audianced to the app based on 
its developer key and bundle_id so that a app cant ask for a token for a 
different site to do correlation. 

It is true that Fido UAF currently requires a web-view to work as the 
authenticator is effectively compiled in to each application, and that 
application has access to the private keys on most platforms (Samsung knox 
being the only exception to that that I know of where the keys are managed by a 
common API to hardware key storage, but they are scoped like U2F as well)

So for the most part it is true and that unless you use the browser to get the 
Fido token the audience is for the app.
Example  Salesforce creates native app that may use enterprise SSO via SAML, 
and the enterprise may use Fido as a authentication factor.
If they use the webview + fido API approach the app can only get a token for 
SalesForce based on its signing key.  It could fire up the web-view and do U2F 
authentication with the enterprise after Salesforec has redirected the user.  
However it will give every enterprise a token audience to Salesforce with a 
salesforce specific key.   If there is a second app for say Slack if they do 
the same thing the enterprise would get a slack audienced token and a slack key 
forcing a separate registration. 

The recommended alternative is that the app use a custom tab for the user to 
SalesForce and that redirect to the enterprise.
The enterprise gets the same token/key with the correct audience from all apps 
on the device using the browser or custom tab. 
The user may not need to signin a second time, and if they do there Fido token 
will not need to be re-registerd.

The Fido API approach really only works for first party apps like PayPal if the 
the app is not doing federation and paypal is doing the authentication for 
there own app.

Token binding private keys have similar issues.   The pool of private keys will 
probably not be shared between apps, and not between the app and the browser 
(Win 10 may be an exception but it is not documented yet)

In the case of using AppAuth with token binding the browser maintains the keys 
so the enterprise would be able to see the same key and use the same cookies 
across all AppAuth Apps.

You can include token binding in your app, however the token bindings and 
cookies are going to be sand boxed per app.  
Depending on implementation the app gets access to the cookie, but perhaps not 
to the private token binding key.  (At least I don't think it will in Android 
embedded webview).

We could expand on this later in an update to the BCP once Web Authentication 
and Token Binding are final.

There are still some unknowns, but in general for any sort of SSO/Federation 
3rd party app I don’t see recommending anything other than a custom tab/ view 
controller/ external browser.

William can take the formatting question:)

John B.
> On Mar 6, 2017, at 4:41 PM, Hannes Tschofenig  
> wrote:
> 
> Hi William, Hi John,
> 
> I just re-read version -8 of the document again.
> 
> Two minor remarks only.
> 
> Editorial issue: Why do you need to introduce a single sub-section 
> within Section 7.1. (namely Section 7.1.1)?
> 
> Background question: You note that embedded user agents have the 
> disadvantage that the app that hosts the embedded user-agent can 
> access the user's full authentication credential. This is certainly 
> true for password-based authentication mechanisms but I wonder whether 
> this is also true for strong authentication techniques, such as those 
> used by FIDO combined with token binding. Have you looked into more 
> modern authentication techniques as well and their security implication?
> 
> Ciao
> Hannes
> 
> On 03/03/2017 07:39 AM, William Denniss wrote:
>> Changes:
>> 
>> – Addresses feedback from the second round of WGLC.
>> – Reordered security consideration sections to better group related topics.
>> – Added complete URI examples to each of the 3 redirect types.
>> – Editorial pass.
>> 
>> 
>> 
>> On Thu, Mar 2, 2017 at 10:27 PM, > > wrote:
>> 
>> 
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>This draft is a work item of the Web Authorization Protocol of the IETF.
>> 
>>Title   : OAuth 2.0 for Native Apps
>>Authors : William Denniss
>>  John Bradley
>>

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

[Anthony Nadalin]

I also think that this can be useful outside of Token Binding as this we have 
been looking at use cases for offline access tokens (or ID Tokens), and this 
sort of forms the basis for this approach

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 2, 2017 7:16 PM
To: John Bradley ; Phil Hunt 
Cc:  
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

+1

Token binding is good, but there are infrastructures that cannot deploy it 
while they still need HoK in some manner.
It could be a short term thing -- perhaps 3 years, but they have to do it now 
so...

I have a question about the draft.

In section 5.1, `key` is optional and when it is omitted, the server creates a 
ephemeral key pair for the client.
My question is: how do you send the ephemeral private key securely to the 
client?
I suppose it is returned in the similar fashion as in the case of the 
symmetric, but it is not clear from my read.

Also, at that point, the authorization server has everything needed to 
impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?

Nat

On Sat, Feb 25, 2017 at 8:51 AM John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
The European banks are interested in mutual TLS for server to server 
connections as part of PSD2/Open Banking.

They have been thinking that they would have central CA and directly use CA 
certificates for all the legs.

I sent them this to get them thinking that they could perhaps secure the token 
endpoint with cert based mutual TLS but allow clients to specify there own keys 
for access tokens to make key rotation and deployment easier.

I was also think ing that they could protect a jwks_uri with the CA certificate 
using OCSP stapling and then use mutual TLS to the token endpoint based on 
keyid and/or fingerprint. allowing for rotation of keys to token endpoint and 
better support clusters with multiple keys.

I don’t think this has much interest outside of some verticals like financials.

John B.
On Feb 24, 2017, at 8:33 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

I have been wondering about that myself. Interest seems to wained with the 
TOKBIND work emerging. Maybe I am wrong about that?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com
phil.h...@oracle.com






On Feb 24, 2017, at 1:58 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

I updated the references but haven't made any other changes.

I had some questions about it so though it was worth keeping alive at-least for 
discussion.

There have been some other questions and proposed changes.

I will take a look through them and see if what may be worth updating.

John B.


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
To: mailto:i-d-annou...@ietf.org>>
Cc: oauth@ietf.org


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

   Title   : OAuth 2.0 Proof-of-Possession: Authorization Server to 
Client Key Distribution
   Authors : John Bradley
 Phil Hunt
 Michael B. Jones
 Hannes Tschofenig
Filename: draft-ietf-oauth-pop-key-distribution-03.txt
Pages   : 18
Date: 2017-02-24

Abstract:
  RFC 6750 specified the bearer token concept for securing access to
  protected resources.  Bearer tokens need to be protected in transit
  as well as at rest.  When a client requests access to a protected
  resource it hands-over the bearer token to the resource server.

  The OAuth 2.0 Proof-of-Possession security concept extends bearer
  token security and requires the client to demonstrate possession of a
  key when accessing a protected resource.

  This document describes how the client obtains this keying material
  from the authorization server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/

There's also a htmlized v

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[Anthony Nadalin]

I would be in favor of this 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 1, 2017 11:10 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics

Hi all,

this is the call for adoption of the 'OAuth Security Topics' document following 
the positive call for adoption at the last IETF meeting in Seoul.

Here is the document:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-lodderstedt-oauth-security-topics-00&data=02%7C01%7Ctonynad%40microsoft.com%7Cdd2d04df662a4bfe36e508d44b3a84e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636216162098338101&sdata=9tMjjKtTBQrNVEEpwfMaIH2gTymyADdgjEJnKU4MP6U%3D&reserved=0

The intention with this document is to have a place to collect discussions and 
conclusions around OAuth 2.0 security and to reference the actual solution 
specifications.

Please let us know by Feb 16th 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

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

[Anthony Nadalin]

We have interoped between FIDO authenticators vendors and Windows Hello

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 4:24 PM
To: Mike Jones ; Anthony Nadalin 
; joel jaeggli ; The IESG 

Cc: oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
draft-ietf-oauth-amr-values-05: (with DISCUSS)



On 02/02/17 00:21, Mike Jones wrote:
> Thanks, Tony.  I can add that reference.
> 
> Stephen, the sets of initial values were chosen from those used in
> practice by Microsoft and Google in real deployments.

Genuine questions: do you aim to have interop between those
deployments? What if I wanted to write code that'd interop
with msft or google?

S.

> 
> About "otp", there are existing use cases for indicating that an OTP
> was used.  I'm not aware of any of these use cases where the
> distinction between TOTP and HOTP is important.  Thus, having "otp"
> now makes sense, where having "hotp" and "totp" now doesn't.
> 
> Stephen, this may seem like splitting hairs, but the registry
> instructions for "Specification Document(s)" are about having a
> reference for the document where the Authentication Method Reference
> Name (such as "otp") is defined.  In all cases for the initial
> values, this is the RFC-to-be, so the registry instructions are
> satisfied.  If someone were, for instance, to define the string
> "hotp", it would be incumbent on the person requesting its
> registration to provide a URL to the document where the string "hotp"
> is defined.  Also having a reference to RFC 4226 in that document
> would be a good thing, but that isn't what the registry instructions
> are about.
> 
> All that said, I can look at also finding appropriate references for
> the remaining values that don't currently have them.  (Anyone got a
> good reference for password or PIN to suggest, for instance?)
> 
> -- Mike
> 
> -Original Message- From: Anthony Nadalin Sent: Wednesday,
> February 1, 2017 4:10 PM To: Stephen Farrell
> ; Mike Jones
> ; joel jaeggli ; The
> IESG  Cc: oauth-cha...@ietf.org;
> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
> 
> 
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones ; joel jaeggli
> ; The IESG  Cc:
> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org;
> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> Hi Mike,
> 
> On 01/02/17 17:00, Mike Jones wrote:
>> Thanks for the discussion, Stephen.
>> 
>> To your point about "otp", the working group discussed this very 
>> point.  They explicitly decided not to introduce "hotp" and "totp" 
>> identifiers because no one had a use case in which the distinction 
>> mattered.
> 
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> 
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> 
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> 
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
> 
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> 
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical and
>> usable value, but not so specific as to make things unnecessarily
>> brittle.
> 
> Eh... don't we want interop? Isn't that the primary goal here?
> 
>> While some might say there's a difference between seria

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

[Anthony Nadalin]

The code point is that Windows Hello protocol supports three types of biometric 
authentication: fingerprint, face and iris, we need to distinguish between eye, 
retina and iris. There are windows devices that do retina also, like windows 
phones, we have now gone to iris after the NIST testing and thus want tto make 
sure there is a way to distinguish during the  authentication since the iris 
scan reduces the probability of error

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 4:15 PM
To: Anthony Nadalin ; Mike Jones 
; joel jaeggli ; The IESG 

Cc: oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Tony,

On 02/02/17 00:10, Anthony Nadalin wrote:
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
> 

Sorry, but that doesn't help me (at first glance anyway). If
there's a reference that'd garner us interop, then great, just
add it to match the codepoint. If there's not, I don't see why
adding a codepoint is useful. (Esp. if we're at the stage of
testing "various iris devices" that I would guess do not get
us interop.)

Am I missing something?

Cheers,
S.

> 
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones ; joel jaeggli
> ; The IESG  Cc:
> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org;
> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> Hi Mike,
> 
> On 01/02/17 17:00, Mike Jones wrote:
>> Thanks for the discussion, Stephen.
>> 
>> To your point about "otp", the working group discussed this very 
>> point.  They explicitly decided not to introduce "hotp" and "totp" 
>> identifiers because no one had a use case in which the distinction 
>> mattered.
> 
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> 
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> 
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> 
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
> 
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> 
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical and
>> usable value, but not so specific as to make things unnecessarily
>> brittle.
> 
> Eh... don't we want interop? Isn't that the primary goal here?
> 
>> While some might say there's a difference between serial number 
>> ranges of particular authentication devices, going there is
>> clearly in the weeds.  On the other hand, while there used to be an
>> "eye" identifier, Elaine Newton of NIST pointed out that there are 
>> significant differences between retina and iris matching, so "eye" 
>> was replaced with "retina" and "iris".  Common sense informed by 
>> actual data is the key here.
> 
> That's another good example. There's no reference for "iris." If that
> is used in some protocol, then what format(s) are expected to be
> supported? Where do I find that spec? If we can answer that, then
> great, let's add the details. If not, then I'd suggest we omit "iris"
> and leave it 'till later to add an entry for that. And again,
> including text with "iris" as an example is just fine, all I'm asking
> is that we only add the registry entry if we can meet the same bar
> that we're asking the DE to impose on later additions.
> 
> And the same for all the others...
> 
> Cheers, S.
> 
> 
>> 
>> The point of the registry requiring a specification reference is
>> so people using

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

[Anthony Nadalin]

NIST asked for the addition of IRIS (as they are seeing more use of IRIS over 
retina due to the accuracy of iris)  as they have been doing significant 
testing on various iris devices and continue to do so, here is a report that 
NIST released 
http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
  

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 2:26 PM
To: Mike Jones ; joel jaeggli ; 
The IESG 
Cc: oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Mike,

On 01/02/17 17:00, Mike Jones wrote:
> Thanks for the discussion, Stephen.
> 
> To your point about "otp", the working group discussed this very
> point.  They explicitly decided not to introduce "hotp" and "totp"
> identifiers because no one had a use case in which the distinction
> mattered.  

Then I'm not following why adding "otp" to the registry now
is a good plan.

If there's a use-case now, then adding an entry with a good
reference to the relevant spec seems right.

If there's no use-case now, then not adding it to the
registry seems right. (Mentioning it as a possible future
entry would be fine.)

I think the same logic would apply for all the values that
this spec adds to the registry. Why is that wrong?

> Others can certainly introduce those identifiers and
> register them if they do have such a use case, once the registry has
> been established.  But the working group wanted to be conservative
> about the identifiers introduced to prime the registry, and this is
> such a case.
> 
> What identifiers to use and register will always be a balancing act.
> You want to be as specific as necessary to add practical and usable
> value, but not so specific as to make things unnecessarily brittle.

Eh... don't we want interop? Isn't that the primary goal here?

> While some might say there's a difference between serial number
> ranges of particular authentication devices, going there is clearly
> in the weeds.  On the other hand, while there used to be an "eye"
> identifier, Elaine Newton of NIST pointed out that there are
> significant differences between retina and iris matching, so "eye"
> was replaced with "retina" and "iris".  Common sense informed by
> actual data is the key here.

That's another good example. There's no reference for "iris." If
that is used in some protocol, then what format(s) are expected
to be supported? Where do I find that spec? If we can answer that,
then great, let's add the details. If not, then I'd suggest we
omit "iris" and leave it 'till later to add an entry for that.
And again, including text with "iris" as an example is just fine,
all I'm asking is that we only add the registry entry if we can
meet the same bar that we're asking the DE to impose on later
additions.

And the same for all the others...

Cheers,
S.


> 
> The point of the registry requiring a specification reference is so
> people using the registry can tell where the identifier is defined.
> For all the initial values, that requirement is satisfied, since the
> reference will be to the new RFC.  I think that aligns with the point
> that Joel was making.
> 
> Your thoughts?
> 
> -- Mike
> 
> -Original Message- From: OAuth
> [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent:
> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli
> ; The IESG  Cc:
> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org;
> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> 
> On 01/02/17 14:58, joel jaeggli wrote:
>> On 1/31/17 8:26 AM, Stephen Farrell wrote:
>>> Stephen Farrell has entered the following ballot position for 
>>> draft-ietf-oauth-amr-values-05: 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 
>>> https://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: 
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>> 
>>> 
>>> 
>>> -
>>>
>>> 
-
>>> DISCUSS: 
>>> -
>>>
>>> 
-
>>> 
>>> This specification seems to me to break it's own rules. You state
>>>  that registrations should include a reference to a specification
>>> to improve interop. And yet, for the strings added here (e.g.
>>> otp) you don't do that (referring to section 2 will not improve
>>> interop) and there are different ways in which many of the
>>

Re: [OAUTH-WG] Future of PoP Work

[Anthony Nadalin]

I would like to see us proceed with the symmetric PoP work in Oauth WG and stop 
the HTTP Signing work all together

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, October 19, 2016 12:54 PM
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Future of PoP Work

In my opinion, at this time, the OAuth WG should not proceed with the symmetric 
implementation of PoP and should not continue work on HTTP signing.

On Wed, Oct 19, 2016 at 12:45 PM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

two questions surfaced at the last IETF meeting, namely

1) Do we want to proceed with the symmetric implementation of PoP or,
alternatively, do we want to move it over to the ACE working group?

2) Do we want to continue the work on HTTP signing?

We would appreciate your input on these two questions.

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

Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation

[Anthony Nadalin]

I’m not aware of any IPR

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Tuesday, September 20, 2016 8:54 PM
To: Mike Jones 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR 
Confirmation

I am aware of no IPR.

Phil

On Sep 19, 2016, at 2:26 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
I am aware of no IPR on this specification.

   -- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, September 19, 2016 2:21 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Authentication Method Reference Values Document: IPR 
Confirmation

Hi Mike, Phil, Tony,


I am working on the shepherd writeup for the AMR document:
https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02

One item in the template requires me to indicate whether each document author 
has confirmed that any and all appropriate IPR disclosures required for full 
conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Could you please confirm?

Ciao
Hannes

___
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] Following up on token exchange use case

[Anthony Nadalin]

Things have gotten so muddled not sure where to begin, the original goal of 
this draft was to provide the function that we use in daily high volume 
production of WS-Trust as we transition to Oauth.  WS-Trust provided many 
options, one was ActAs and the other was OnBehalfOf, these were 2 distinct 
functions but could be combined (and thus the results are of a composite 
nature). There were also other options like delegateTo, Forwardable and 
Delegatable. So we have use cases for all these.

So we have straight forward scenarios for (1) a token request to be on behalf 
of a given/specified token, we also have a straight forward scenario for (2) 
requesting a token based upon a specific token. We also have complex scenarios 
for combining the semantics of both  (1) and (2) where the token request is on 
behalf of a specific token and the request is based upon a specific token, this 
happened a lot in our server to server scenarios for access to backend 
documents and services. Where we have chained services this is where the 
delegateTo, Forwardable and Delegatable options come into the scenario.

The way that this current specification is structured and written the Subject 
is always required which is a not a good thing since there may not be a 
subject, as basic token requests don’t have to have subjects (just 
authentication credentials), thus you can’t get the semantics of (2) without 
(1). Now the semantics of combing (1) and (2) seem to be not understood and 
wanting to be removed.


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Saturday, August 27, 2016 3:26 PM
To: Brian Campbell 
Cc:  
Subject: Re: [OAUTH-WG] Following up on token exchange use case

No objections. Simplification is better, and this spec is already fairly 
convoluted with all the options turned on.

 — Justin

On Aug 26, 2016, at 1:30 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Looking for two things here:
1) Any objections to removing the want_composite request parameter? Please 
explain, if so. I plan to remove it in the next draft barring an outpouring of 
support to keep it.
2) Tony to explain his use case and describe what changes would be needed to 
accommodate it.

On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
During the meeting in Berlin Tony voiced concern about a use case he had for 
token exchange. Honestly, it's still not entirely clear to me what that use 
case is or what would need to change in support of it. I'd like to better 
understand the use case and see if it's something that can reasonably be 
accommodated with Token Exchange. During the meeting Tony referred back to an 
earlier email where he said, "want_composite is not really the effect we are 
looking for since it provides for a single token, the use case we have is where 
you want the ability to use the subject_token and the actor_token in 
combination and not as a composite of only the claims."
The want_composite parameter came about during some iterative work on the 
document (between I-D publications) last year. At first the client could 
express that it wanted a composite token, one containing delegation semantics, 
with the inclusion of the actor_token parameter. One of the other editors 
suggested, however, that the actor_token token might be necessary for 
authorization in cases even when the client wasn't asking for a composite token 
and that placing the desire for delegation semantics on it was overloading the 
parameter too much. I introduced the want_composite parameter to give the 
client such a signal independent of the actor_token parameter. My (admittedly 
incomplete) understanding of WS-Trust is that the client/requester can make 
such an indication and I was trying to follow that model. However, I'm not sure 
it's needed or even makes much much sense. Ultimately it's the server's 
decision about how to construct the issued token and what to include in it. It 
is the server's policy, not a client signal, which makes the determination. So 
the want_composite parameter is really just noise that makes the spec longer. 
And, from the quote above, seems might also lead some readers to incorrect 
conclusions about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.


___
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] Call for adoption: Token Binding for OAuth 2.0

[Anthony Nadalin]

I’m OK with the 
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
 but not sure that 
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
 is a good starting point as we would want a more generic solution for PoP 
tokens in general


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, August 16, 2016 11:45 AM
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

Just a friendly reminder that the 'deadline' for this call for adoption is 
tomorrow.

According to the minutes from 
Berlin,
 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were against.

On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

this is the call for adoption of the 'OAuth 2.0 Token Binding' document
bundle* following the positive call for adoption at the recent IETF
meeting in Berlin.

Here are the links to the documents presented at the last IETF meeting:
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

Please let us know by August 17th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek

*: We will find out what the best document structure is later, i.e.,
whether the content should be included in one, two or multiple documents.


___
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] OAuth Security -- Next Steps

[Anthony Nadalin]

Sounds about right, but I would imagine that the BCP would cover any issue that 
arises not just mix-up

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, July 25, 2016 3:59 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Security -- Next Steps

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am happy 
about the progress on many of the subjects. We managed to progress token 
exchange, native apps, AMR, and authorization server meta-data. We also 
identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding functionality, which 
still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make some 
progress on the mix-up mitigation and on the wider range of security documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack (only 
mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to be modified 
to reflect the preference of the working group. My impression (from speaking 
with participants at the meeting last week
privately) is that there is interest in a solution that does not require 
protocol changes but rather relies on configuration. This may include a 
combination of exact redirect_URI matching + per-AS redirect_URI + session 
state checking. There are also other attacks described in 
draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to 
avoid confusion.

2) We need a new document, ideally a BCP, that serves as a high-level write-up 
describing various security issues with OAuth that points to the mostly 
existing documents for those who want to read the background information. 
Torsten has posted a mail to the list providing one possible outline of such a 
document.

How does this sound?

Ciao
Hannes

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

Re: [OAUTH-WG] RT treatment in Token Exchange

[Anthony Nadalin]

So I think the proposed wording is still too specific and limits the use case , 
I also don’t understand the usage of “credential” in your description as this 
does not have to be a credential. So suggest that this be simple and if you 
want you can explain in the security considerations section why one may not 
want to return a refresh_token

OPTIONAL.  The refresh_token for the issued token in the token_exchange request

access_token (response), this does not have to be an access_token so this is a 
bad name


Also it’s unclear why the subject_token is required, is it being suggested that 
the subject_token is also being used as an access_token ? The actor_token if 
specified could also be the subject_token

The term “security_token” I assume is not limited to access_token since there 
is a subject_token_type.

want_composite is not really the effect we are looking for since it provides 
for a single token, the use case we have is where you want the ability to use 
the subject_token and the actor_token in combination and not as a composite of 
only the claims.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, July 5, 2016 11:16 AM
To: oauth 
Subject: [OAUTH-WG] RT treatment in Token Exchange

I gave a short presentation about OAuth 2.0 Token 
Exchange
 at a recent identity conference, which seemed well received and a lot of folks 
expressed their support for it and a desire to see support for it in offerings 
out in the wild.
However, I did get some feedback from Vittorio Bertocci of Microsoft that he 
felt that the language around issuing refresh tokens was overly restrictive 
based on real world deployment experience they have with a token exchange like 
interaction that they are currently offering. He described it as follows:
"To summarize our main use case: we use [a token exchange like protocol] for 
achieving user impersonation thru tiers, or delegation for confidential clients 
which do not have any web UX.

Those cases do call for the ability of the middle tier to access the resource 
also when the original credential is no longer valid (e.g. there is no longer 
any user entertaining an active session with the middle tier).

Think of a hypothetical new feature of the Uber mobile app, which can monitor 
your Exchange calendar and book a ride whenever a suitable slot opens up within 
a certain time range. The Uber app would call an Uber-owned middle tier, in 
form of Web API, and the Web API would itself be a client of the Exchange API. 
Given that the Uber API doesn’t offer any browser ready surface, as it is meant 
to be accessed only via oauth2 bearer token, the [token exchange] is the only 
way through which it can obtain a token for the Exchange API; and the scenario 
definitely call for offline access, as the uber API should be able to monitor 
the Exchange calendar of the user even if the user closed the app on his/her 
phone."

While the current text in the draft allows for this kind of thing, it 
stigmatizes it somewhat with a "NOT RECOMMENDED" on sending an RT in the 
response. So the proposal here is to make refresh tokens OPTIONAL and change 
the accompanying text in sec 2.2.1 to the following:

   refresh_token
  OPTIONAL.  A refresh token will typically not be issued when the
  the exchange is of one temporary credential (the subject_token)
  for a different temporary credential (the issued token) for use in
  some other context.  A refresh token can be issued in cases where
  the client of the token exchange needs the ability to access a
  resource even when the original credential is no longer valid
  (e.g. user-not-present or offline scenarios where there is no
  longer any user entertaining an active session with the client).
  Profiles or deployments of this specification should clearly
  document the conditions under which a client should expect a
  refresh token in response to "urn:ietf:params:oauth:grant-
  type:token-exchange" grant type requests.
I plan to make the aforementioned change and get a new draft published with 
that and some other updates later this week before the Internet Draft 
submission cut-off on Friday.



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

Re: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request

[Anthony Nadalin]

Sounds appropriate

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, June 20, 2016 10:16 AM
To: oauth 
Subject: [OAUTH-WG] closing an open issue about supplementary info in the Token 
Exchange request

A good while back in an off list conversation about Token Exchange, Chuck 
Mortimore mentioned that they "had a use-case for custom claims in where they 
essentially wanted to carry along metadata about a client or device for 
association to objects in our cloud." As a result of that conversation I added 
the bullet item to the Open Issues section that says, "Provide a way to include 
supplementary claims or information in the request that would/could potentially 
be included in the issued token.", which has just been kinda sitting there ever 
since with no action being taken on it.
I recently had the opportunity to see Chuck present about some work that they 
are doing for IoT, which utilizes a number of items from this WG including 
Token Exchange. It turns out that they were able to accommodate that use-case 
of expressing metadata about a client or device by using the actor_token.  
There's a paper about the work at 
https://www.salesforceidentity.info/Using_Asset_Tokens.pdf
 if anyone is interested in more details.
Because the use-case behind that open issue is met by the existing constructs 
of the document, I'm proposing that no new parameters or tokens be introduced 
and that the open issue be removed and considered done in the next revision of 
the Token Exchange draft. Please speak up soon, if you believe this is a 
mistake.

Thanks,
Brian



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

Re: [OAUTH-WG] Reminder: OAuth Security Workshop

[Anthony Nadalin]

Can I also suggest that a PayPal or Credit Card payment be added as a means as 
bank transfer for corporate folks is like impossible 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Monday, May 16, 2016 4:25 AM
To: Hannes Tschofenig ; oauth@ietf.org; Daniel Fett 

Subject: Re: [OAUTH-WG] Reminder: OAuth Security Workshop

I'm planning to submit a position paper to the OAuth security workshop.  I 
couldn't find any guidance on what the program committee is looking for in the 
papers.  I could imagine anything from submitting a paragraph or two describing 
the conversations I'd like to lead to a 10-page paper suitable for 
peer-reviewed publication, or anything in between.  What were you looking for?

Also, will the position papers be published in a workshop proceedings or will 
they be used only for determining who will be invited to participate?

Thanks,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 16, 2016 3:31 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Reminder: OAuth Security Workshop

Hi all,

this is a reminder that the call for position paper deadline for the OAuth 
Security Workshop is getting closer.

Here is the link to the info:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2finfsec.uni-trier.de%2fevents%2fosw2016&data=01%7c01%7ctonynad%40microsoft.com%7c17bb7f6c7065422371df08d37d7cd18b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NOKnwv9A439uCCz89MtiIDSjQZGNlUNo4zXibDGwotI%3d

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c17bb7f6c7065422371df08d37d7cd18b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2ARrqLXQ5QQ7d8gvrm%2bqaXmyXrhl3Q10kOc7X5usag4%3d

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

Re: [OAUTH-WG] Multi-AS State Re-Use

[Anthony Nadalin]

STATE can be anything, it does not have to be a NONCE so changing this would 
cause issues at this time for existing deployments

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, May 9, 2016 7:34 PM
To: Guido Schmitz ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Multi-AS State Re-Use

As far as I am aware of, state was meant to be nonce. Replay possibility etc. 
were known. It is probably a bad documentation that every reviewers missed 
because they were assuming it.

Best,

Nat
On Mon, May 9, 2016 at 20:14 Guido Schmitz 
mailto:g.schm...@gtrs.de>> wrote:
Hi all,

can anybody confirm that this is a new / undocumented attack?

Cheers,

Guido, Daniel, and Ralf

On 22.04.2016 16:23, Daniel Fett wrote:
> Hi all,
>
> Besides the state leakage attack we found that another important fact
> regarding state is underspecified: Each state value should only be
> used for one run of the protocol, in particular, each AS should see a
> different state in multi-AS settings. Clients might be tempted to
> generate state once and then re-use each time a user wants to
> authorize.
>
> If state is re-used, given a setup where one Client allows users to
> authorize using two AS, a potentially malicious AS learns the state
> value that is valid for authorization at an honest AS. I.e., each AS
> can mount a CSRF attack on the user using the other AS.
>
> Just as the attack in the other mail, this is not a big deal in
> practice, but should be discussed somewhere.
>
> Cheers,
> Daniel, Guido, and Ralf
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

Specifications should be somewhat complete and not open ended/not thought out, 
you should think about the issues, requirements and use cases first before you 
try to force this into the working group process and confuse people , we had 
too many of these specifications lately.

We are now up to 15+ specifications that someone has to read and understand how 
these all may or may not fit together and all the interactions that may occur. 
So much for the simple Oauth.

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Tuesday, April 12, 2016 5:46 AM
To: Torsten Lodderstadt 
Cc: Anthony Nadalin ;  
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

+1 to Torsten’s point.

And a reminder to Tony that call for adoption is the *start* of the document 
editing process, not the end. We’re not saying this is a complete solution with 
everything thought out when we adopt the document, we’re saying it’s a problem 
we want to work on and a direction that we want to move in. Stop trying to 
confuse people.

 — Justin

On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:

Indicating the resource server to the AS allows the AS to automatically select 
token type, encryption scheme and user data to be put into the access token 
based on a RS-specific policy. So there is no need to explicitely ask the AS 
for a certain token format or encryption scheme.

Am 11.04.2016 um 22:35 schrieb Anthony Nadalin 
mailto:tony...@microsoft.com>>:
So it’s an incomplete solution then ?

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, April 11, 2016 1:34 PM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: Nat Sakimura mailto:sakim...@gmail.com>>; 
mailto:oauth@ietf.org>> mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

No, I'm not adding requirements for encryption. I was pointing out some of the 
ways that an access token might be different for different RSs.



On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
So now you are adding more requirements for encryption ? The more this thread 
goes on shows how unstable and not fully thought out this draft is to go 
through WG adoption.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Sending a token type is not sufficient. There's more involved than the format. 
Many cases need to know if to encrypt and whom to encrypt to.  What claims to 
put in the token (or reference by the token). What algorithms and keys to use 
for signing/encryption.

The statement that the "Current proposal does not support the implicit flow" is 
incorrect. Among other things, sec 2 has, "When an access token will be 
returned from the authorization endpoint, the "resource" parameter is used in 
the authorization request to the authorization endpoint as defined in Section 
4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
So, my understanding on the rationale/requirements for having this spec right 
now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format 
depending on the resource server and to do that, you need to know which RS is 
gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to 
audience restrict the token, but the same can be achieved by sender 
constraining the token, e.g., by token binding. As far as I can see, the 
sentiment of the WG seems to be to use the sender constraint through Token 
Binding, so from this respect, this spec is not the one to do R1. Besides, the 
current proposal only takes care of the code flow. The same requirement should 
be there for implicit flow as well, so the current proposal is not covering the 
R1 anyways.

I can sort of understand R2, but I have two critique on the current proposal:

C1. Current proposal does not support the implicit flow. To support it, the 
resource URI has to be sent to the Authz endpoint instead of the Token endpoint.
C2. It is much more direct to send the required token format rather than the RS 
uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs that it 
supports, e.g., AOL.
   In such a case, even if the RS uri were sent to the AS, the AS cannot 
mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information about 
the resource that the client is going to the browser.
  3) There 

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

[Anthony Nadalin]

So it’s an incomplete solution then ?

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, April 11, 2016 1:34 PM
To: Anthony Nadalin 
Cc: Nat Sakimura ;  
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

No, I'm not adding requirements for encryption. I was pointing out some of the 
ways that an access token might be different for different RSs.


On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
So now you are adding more requirements for encryption ? The more this thread 
goes on shows how unstable and not fully thought out this draft is to go 
through WG adoption.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Sending a token type is not sufficient. There's more involved than the format. 
Many cases need to know if to encrypt and whom to encrypt to.  What claims to 
put in the token (or reference by the token). What algorithms and keys to use 
for signing/encryption.

The statement that the "Current proposal does not support the implicit flow" is 
incorrect. Among other things, sec 2 has, "When an access token will be 
returned from the authorization endpoint, the "resource" parameter is used in 
the authorization request to the authorization endpoint as defined in Section 
4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
So, my understanding on the rationale/requirements for having this spec right 
now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format 
depending on the resource server and to do that, you need to know which RS is 
gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to 
audience restrict the token, but the same can be achieved by sender 
constraining the token, e.g., by token binding. As far as I can see, the 
sentiment of the WG seems to be to use the sender constraint through Token 
Binding, so from this respect, this spec is not the one to do R1. Besides, the 
current proposal only takes care of the code flow. The same requirement should 
be there for implicit flow as well, so the current proposal is not covering the 
R1 anyways.

I can sort of understand R2, but I have two critique on the current proposal:

C1. Current proposal does not support the implicit flow. To support it, the 
resource URI has to be sent to the Authz endpoint instead of the Token endpoint.
C2. It is much more direct to send the required token format rather than the RS 
uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs that it 
supports, e.g., AOL.
   In such a case, even if the RS uri were sent to the AS, the AS cannot 
mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information about 
the resource that the client is going to the browser.
  3) There are use cases where it is desirable not to let the AS knows where 
the Client is going from the privacy point of view.

So, my suggestion is to drop R1 and concentrate on R2. And to solve R2, send 
token type instead of the resource indicator in the request.
This also necessitates the Client to be able to find out what token type the 
resource requires, perhaps in the unauthorized response web link header at the 
resource in the manner of oauth-meta.

Cheers,

Nat



2016年4月8日(金) 8:23 Prateek Mishra 
mailto:prateek.mis...@oracle.com>>:
While this work addresses a gap in the existing OAuth specification set, I am 
very concerned that this
incremental extension will lead to even more confusion around the areas of 
“scope”, “audience” and “resource server”.

I think we should try to solve this problem via  a framework that provides 
better guidance and implementation
models for OAuth use-cases. In other words, I feel that a broader discussion is 
needed here.


> On Apr 7, 2016, at 4:11 PM, Justin Richer 
> mailto:jric...@mit.edu>> wrote:
>
> I support adoption of this document as a starting point for working group 
> work.
>
> — Justin
>
>
>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>
>> Hi all,
>>
>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbe

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

[Anthony Nadalin]

So now you are adding more requirements for encryption ? The more this thread 
goes on shows how unstable and not fully thought out this draft is to go 
through WG adoption.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Sending a token type is not sufficient. There's more involved than the format. 
Many cases need to know if to encrypt and whom to encrypt to.  What claims to 
put in the token (or reference by the token). What algorithms and keys to use 
for signing/encryption.

The statement that the "Current proposal does not support the implicit flow" is 
incorrect. Among other things, sec 2 has, "When an access token will be 
returned from the authorization endpoint, the "resource" parameter is used in 
the authorization request to the authorization endpoint as defined in Section 
4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
So, my understanding on the rationale/requirements for having this spec right 
now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format 
depending on the resource server and to do that, you need to know which RS is 
gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to 
audience restrict the token, but the same can be achieved by sender 
constraining the token, e.g., by token binding. As far as I can see, the 
sentiment of the WG seems to be to use the sender constraint through Token 
Binding, so from this respect, this spec is not the one to do R1. Besides, the 
current proposal only takes care of the code flow. The same requirement should 
be there for implicit flow as well, so the current proposal is not covering the 
R1 anyways.

I can sort of understand R2, but I have two critique on the current proposal:

C1. Current proposal does not support the implicit flow. To support it, the 
resource URI has to be sent to the Authz endpoint instead of the Token endpoint.
C2. It is much more direct to send the required token format rather than the RS 
uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs that it 
supports, e.g., AOL.
   In such a case, even if the RS uri were sent to the AS, the AS cannot 
mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information about 
the resource that the client is going to the browser.
  3) There are use cases where it is desirable not to let the AS knows where 
the Client is going from the privacy point of view.

So, my suggestion is to drop R1 and concentrate on R2. And to solve R2, send 
token type instead of the resource indicator in the request.
This also necessitates the Client to be able to find out what token type the 
resource requires, perhaps in the unauthorized response web link header at the 
resource in the manner of oauth-meta.

Cheers,

Nat



2016年4月8日(金) 8:23 Prateek Mishra 
mailto:prateek.mis...@oracle.com>>:
While this work addresses a gap in the existing OAuth specification set, I am 
very concerned that this
incremental extension will lead to even more confusion around the areas of 
“scope”, “audience” and “resource server”.

I think we should try to solve this problem via  a framework that provides 
better guidance and implementation
models for OAuth use-cases. In other words, I feel that a broader discussion is 
needed here.


> On Apr 7, 2016, at 4:11 PM, Justin Richer 
> mailto:jric...@mit.edu>> wrote:
>
> I support adoption of this document as a starting point for working group 
> work.
>
> — Justin
>
>
>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>
>> Hi all,
>>
>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>
>> Please let us know by April 20th 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 Buenos
>> Aires then you don't need to re-state your opinion, if you want.
>>
>> The feedback at the BA IETF meeting was the following: ~10 persons
>> for accepting the document and 0 persons against.
>>
>> Ciao
>> Hannes & Derek
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https

[OAUTH-WG] Token Binding and RFC5705

[Anthony Nadalin]

At the informal Token Binding meeting we had a discussion of Java servers 
supporting TB, the support would have to come out of JSSE, kere is the analysis 
on what it would take to change JSSE

Implementing 5705 itself, would not take too long and appears to be pretty 
straightforward.  The EKM is created by using the same PRF function as the 
creating of the key material from the TLS Master secret.
In TLS,

To generate the key material, compute



  key_block = PRF(SecurityParameters.master_secret,

  "key expansion",

  SecurityParameters.server_random +

  SecurityParameters.client_random);

For EKM,

If no context is provided, it then computes:



   PRF(SecurityParameters.master_secret, label,

   SecurityParameters.client_random +

   SecurityParameters.server_random

   )[length]



   If context is provided, it computes:



   PRF(SecurityParameters.master_secret, label,

   SecurityParameters.client_random +

   SecurityParameters.server_random +

   context_value_length + context_value

   )[length]

As it states in the RFC:  "The issue is the designing a secure mechanism that 
uses exporters is not necessarily straightforward. This document only provides 
the exporter mechanism, but the problem of agreeing on the surrounding context 
and the meaning of the information passed to and from the exporter remains. Any 
new uses of the exporter mechanism should be subject to careful review."

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

Re: [OAUTH-WG] OAuth 2.1

[Anthony Nadalin]

I don't belive that scopes should be defined more precisely as this opaqueness 
was a design feature, I'm not seeing the reason why scopes need to be defined, 
as these are application specific.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, April 7, 2016 5:32 AM
To: George Fletcher 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi all,

as I already said in the meeting: I would very much prefer to have an 
extension/update of RFC 6819 covering all "new" threats, including:
- mix up
- code injection aka copy and paste
- open redirector at AS and client
- potential other threats in the context of "dynamic" OAuth

I also assume mitigations for (at least some of) the threats need to go into an 
update of RFC 6749 as normative text. To give an example: if we agree on using 
the state parameter at the token endpoint to mitigate code injection, this MUST 
be part of the core spec (request description and security consoderations). 
Otherwise, noone will even  consider it.

We should also use the opportunity to improve/enhance the text of the spec. In 
the course of the last years, we have learned a lot about ambiquities of the 
text and how different implementations utilize OAuth. 

I think time is right to define scopes more precisely. As the discussions in 
the last days proved again (at least for me), scope is not sufficiently defined 
to come up with interoperable implementations. Additionally, there seems to be 
a need to represent resource server locations (to not say identities :-)) in 
this context.

To bundle all changes in a version 2.1 would also make communication into the 
market much easier. 

best regards,
Torsten.

> Am 06.04.2016 um 16:05 schrieb George Fletcher :
> 
> I'd definitely prefer a single solution document to many little ones that 
> have to be combined to actually build a secure solution. It's already getting 
> complex with the additional specs that have been added.
> 
> Additionally, I'm not against working on OAuth 2.1.
> 
> Thanks,
> George
> 
>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>  
>> Existing implementations are for the large part ok and do not need these 
>> mitigations.
>> 
>> Only the new use cases we have been discussing (configure on the fly and 
>> multi-as, etc) really need mitigation.
>> 
>> The updated by approach seems like a good way to address the new cases.
>> 
>> Phil
>> 
>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> today we discussed the OAuth Authorization Server Mixup draft. We 
>>> were wondering what types of threats the document should find solutions for.
>>> 
>>> We discussed various document handling approaches including
>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate 
>>> solution documents
>>> * combined solution document covering the OAuth Mix-Up and the 
>>> Cut-and-Paste attacks.
>>> 
>>> Barry pointed out that these documents could update the OAuth base 
>>> specification.
>>> 
>>> As a more radical change it was also suggested to revise RFC 6749 
>>> "OAuth
>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model 
>>> and Security Considerations".
>>> 
>>> Opening up the OAuth base specification obviously raises various 
>>> other questions about cleaning up parts that go far beyond the AS 
>>> mix-up and the cut-and-paste attacks. Other specifications, such as 
>>> the Open Redirector, could be folded into such a new specification.
>>> 
>>> Derek and I would appreciate your input on this topic before we make 
>>> a decision since it has significant impact on our work.
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2
>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c
>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsof
> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01
> 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org

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

[Anthony Nadalin]

I don’t see anything in the document that allows multiple resource servers 
where the token can be used. Token Exchange allows delegation and 
impersonation, so I have no idea of the semantics when I use both of these 
together

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday, April 6, 2016 1:13 PM
To: Anthony Nadalin 
Cc: Phil Hunt (IDM) ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Multiple resources are there now.
I have no idea what "interaction with Token Exchange" means. Can you please 
explain?

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
I would like to see the multiple resources servers, interaction with Token 
Exchange resolved before this is adopted to see if this will actually solve the 
problems

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

I support the adoption of this draft by the working group.
I don't think an immediate WGLC was expected here.

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:
With the process of immediate wglc I think we should review all documents more 
thoroughly before adoption.

As I said I support the work.

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig 
> mailto:hannes.tschofe...@gmx.net>> wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates back
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig 
>>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=byM3LOXoRTVhgT8pECwr18fH8mpi69bReWGFiuOEbMA%3d>
>>>
>>> Please let us know by April 20th 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 Buenos
>>> Aires then you don't need to re-state your opinion, if you want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 persons
>>> for accepting the document and 0 persons against.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org<mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>
>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>


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

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

[Anthony Nadalin]

I would like to see the multiple resources servers, interaction with Token 
Exchange resolved before this is adopted to see if this will actually solve the 
problems

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

I support the adoption of this draft by the working group.
I don't think an immediate WGLC was expected here.

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:
With the process of immediate wglc I think we should review all documents more 
thoroughly before adoption.

As I said I support the work.

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig 
> mailto:hannes.tschofe...@gmx.net>> wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates back
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig 
>>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>>
>>> Please let us know by April 20th 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 Buenos
>>> Aires then you don't need to re-state your opinion, if you want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 persons
>>> for accepting the document and 0 persons against.
>>>
>>> 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] Informal Discussion about Discovery Today at 16:20

[Anthony Nadalin]

Wasn't this the task of the design team ?

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 6, 2016 10:48 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20

Hi all,

during the f2f meeting today the suggestion was made to have another informal 
discussion about OAuth discovery.

We are going to meet at 16:20 today at the **IETF registration desk**.
William is trying to find a meeting room for us.

Please respond to me privately about this event, if you have feedback.

Ciao
Hannes

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

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

[Anthony Nadalin]

Good question, since SCIM does not really provide an authorization model and 
Oauth does not do provisioning this is sort of caught in the middle, so if I 
had to pick I would pick Oauth as this is a generic server to server issue

From: Hardt, Dick [mailto:d...@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin 
Cc: Gil Kirkpatrick ; Nat Sakimura 
; Phil Hunt (IDM) ; s...@ietf.org; 
oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

Sounds like there is interest.

SCIM or OAUTH?

-- Dick

On Apr 6, 2016, at 8:57 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
I would be interested also

Sent from my Windows 10 phone

From: Gil Kirkpatrick<mailto:gil.kirkpatr...@viewds.com>
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'<mailto:n-sakim...@nri.co.jp>; 'Hardt, 
Dick'<mailto:d...@amazon.com>; 'Phil Hunt (IDM)'<mailto:phil.h...@oracle.com>
Cc: s...@ietf.org<mailto:s...@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

That's an issue we're facing as well. Definitely interested.

-gil

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' mailto:d...@amazon.com>>; 'Phil Hunt (IDM)' 
mailto:phil.h...@oracle.com>>
Cc: s...@ietf.org<mailto:s...@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

+1 for removing the manual cut-n-pastes!

Nat

--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.

From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>
Cc: s...@ietf.org<mailto:s...@ietf.org>; oauth@ietf.org<mailto: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)" 
mailto:scim-boun...@ietf.org> on behalf of 
phil.h...@oracle.com<mailto:phil.h...@oracle.com>> 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 mailto:d...@amazon.com>> 
wrote:
Use case: An admin for an organization would like to enable her users to access 
a SaaS application at her IdP.

User experience:

  1.  Admin authenticates to IdP in browser
  2.  Admin selects SaaS app to federate with from list at IdP
  3.  IdP optionally presents config options
  4.  IdP redirects Admin to SaaS app
  5.  Admin authenticates to SaaS app
  6.  SaaS app optionally gathers config options
  7.  SaaS app redirects admin to IdP
  8.  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<mailto:s...@ietf.org>
https://www.ietf.org/mailman/listinfo/scim<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fscim&data=01%7c01%7ctonynad%40microsoft.com%7c871da74138de485b0bb008d35deb6643%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fILmgXPgRyLfCIn%2b2EbpBbIcHqKJbKZVYKJBpUL%2fKnY%3d>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

I would be interested also

Sent from my Windows 10 phone

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, 
Dick'; 'Phil Hunt (IDM)'
Cc: s...@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

That's an issue we're facing as well. Definitely interested.

-gil

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' ; 'Phil Hunt (IDM)' 
Cc: s...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

+1 for removing the manual cut-n-pastes!

Nat

--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.

From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>
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)" 
mailto:scim-boun...@ietf.org> on behalf of 
phil.h...@oracle.com> 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 mailto:d...@amazon.com>> 
wrote:
Use case: An admin for an organization would like to enable her users to access 
a SaaS application at her IdP.

User experience:

  1.  Admin authenticates to IdP in browser
  2.  Admin selects SaaS app to federate with from list at IdP
  3.  IdP optionally presents config options
  4.  IdP redirects Admin to SaaS app
  5.  Admin authenticates to SaaS app
  6.  SaaS app optionally gathers config options
  7.  SaaS app redirects admin to IdP
  8.  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

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

Pushing documents such as AS metadata because Connect uses them does not help 
anything but muddies the water, Metadata is not a solution to Mix-up and 
Metadata is not a solution to Discovery, both Discovery and Mix-up are problems 
we need and agreed to fix. So I totally agree that we should not be conflating 
metadata with Mix-up or Discovery. I’m not hearing overwhelming consensus on 
adopting the metadata, maybe that is just consensus amongst OpenID folks and 
yes there are a few vocal people.

Most RS and AS relationships are not static relationships, we are seeing 
tenants that are suppling their own AS infrastructure as well as seeing 
portable RS’s which gets us into some very dynamic situations.



From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, March 15, 2016 8:00 AM
To: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

Discovery in general for OAuth isn't well understood. This conversation and 
others like it around the 'discovery' draft demonstrate that. But publishing AS 
metadata is something that is understood and already in wide use for Connect. 
The rough consensus (except for a very few but vocal dissenters) on this list 
over the last few weeks/months has been that draft-ietf-oauth-discovery should 
describing AS metadata and its location. It's been suggested that the title 
reflect that scope and I might even suggest that the document identifier be 
changed to avoid further confusion.
The IDP mixup is addressed by the AS identifying itself to the client in the 
authorization response (it has a few other things in it that arguably shouldn't 
be in or should be elsewhere but that's a different question). The Mix-Up 
Mitigation draft uses the issuer value to do that. Issuer becomes a logical 
name/identifier for an AS. And that can tie it to AS metadata or even discovery 
if/when that exists. But discovery or AS metadata isn't necessary there. Yes 
Tony, we'd all like to see a comprehensive solution but conflating different 
and unrelated things is only making matters worse (as I'm sure you are well 
aware).
A 'bad RS' phishing for legitimate access tokens is a different kind of 
endpoint confusion. Most deployments now have a static relationship defined 
between RS and AS so it's more of a potential problem in the future. Despite 
the concern voiced about it the potential (as far as I can tell anyway), 
draft-hunt-oauth-bound-config provides a very nice attack vector for such a 
'bad RS' by pointing to an AS to obtain tokens it could misuse at legitimate 
RS(s). John has alluded to this.

There have been a number of incremental updates/extensions to OAuth 2.0 and 
there look to be more coming.  Concerns have been expressed over the number of 
documents and implements knowing what to use when. I don't think the answer is 
to try and jam unrelated new stuff into new docs to keep the number of docs low 
is a good idea though. I'd much prefer to have concise and cohesive documents. 
The larger issue of confusion around too many documents should be addressed at 
a higher level. For example, something like an implementation guide or even 
something like an OAuth 2.1 that describes the available extensions and 
when/why one would use them.



On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
I would really like to see a comprehensive solution not this piece work, so we 
know what we are solving and what we are not.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; John 
Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley 
> mailto:ve7...@ve7jtb.com>
> <mailto:ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>> wrote:
>> Any client that has the resource and issuer hard coded probably
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other, 
regardless of the fact that a Discovery solution *could* solve the IDP mixup 
attack as well.

Hans.

--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com<mailto:hzandb...@pingidentity.com> | Ping Identity

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

I would really like to see a comprehensive solution not this piece work, so we 
know what we are solving and what we are not.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) ; John Bradley 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley  > wrote:
>> Any client that has the resource and issuer hard coded probably 
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other, 
regardless of the fact that a Discovery solution *could* solve the IDP mixup 
attack as well.

Hans.

-- 
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d

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

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

T are presented as part of 
the protocol rather then dragging discovery in as a requirement.

In my opinion the resource the token is targeted to should be separated from 
the scope and returned as part of the meta-data about the AT along with scopes 
granted and expiry time.   We should also have a input parameter for resources 
so that a client can restrict tokens issued to a subset of the ones granted by 
the refresh token.   It would then also be possible to ask a AS for a token for 
a unregistered RS and have the AS produce a JWT access token with the resource 
as an audience if policy allows.

That however was supposed to be dealt with as part of the mixed up client set 
of mitigations.
In that the goal was to mitigate the attacks by returning meta-data about the 
tokens, and not to require discovery.

We intend to return “iss” and “cleint_id” for the code, and I intend to discuss 
at the F2F returning resource for AT as well.

Those mitigate the attack.

I will continue to resist mixing up discovery of configuration meta-data with 
mitigation of the attacks.

We return meta-data about the tokens now, because AT are opaque to the client, 
we neglected to include some of the information for the client needs to be 
secure.   We just need to add that in to the existing flows.

While Phil’s proposal is easier for the AS to implement as an add on, it puts 
more of a burden on the client needing to potentially change how it stores the 
relationships between AS and RS to prevent compromise, I think the solution 
should be biased towards simplicity on the client side.

If we return the resources as part of the existing meta data the client checks 
that against the resource it intends to send the token to and if it is not in 
the list then it can’t send the token.  Simple check every time it gets a new 
AT, no optionality.

I am not saying anything new Nat has been advocating basically this for some 
time, and dis submit a draft.   I prefer to return the info in the existing 
format rather than as link headers,  but that is the largest difference between 
what Nat and I are saying with respect to resource.

That is the core of my problem with Phil’s draft.

I guess we will need to have a long conversation in BA.

Regards
John B.

On Mar 13, 2016, at 8:12 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

This draft is a proposed alternate proposal for draft-ietf-oauth-discovery.  As 
such, it contains the same registry for OAuth Config Metadata as the authors 
believe that both solutions are not required, or depending on WG discussion 
they will be merged. The intent is to provide a simple complete draft for 
consideration.

How it works...
Given that a client has previously discovered an OAuth protected resource, the 
bound configuration method allows a client to return the configuration for an 
oauth authorization server that can issue tokens for the resource URI specified 
by the client.  The AS is not required to be in the same domain.  The AS is 
however required to know if it can issue tokens for a resource service (which 
presumes some agreement exists on tokens etc).

The draft does not require that the resource exist (e.g. for unconfigured or 
new user based resources). It only requires that the AS service provider agrees 
it can issue tokens.

From a security perspective, returning the OAuth service configuration for a 
specified resource URI serves to confirm the client is in possession of a valid 
resource URI ensuring the client has received a valid set of endpoints for the 
resource and the associated oauth services.

I propose that the WG consider the alternate draft carefully as well as other 
submissions and evaluate the broader discovery problem before proceeding with 
WGLC on OAuth Discovery.

Thanks!

Phil

@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.independentid.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wYX1bvmaiwFUTnQfR4mcHcmzYtNA9K19vVwgPX%2fFki4%3d>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>


Begin forwarded message:

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Subject: New Version Notification for draft-hunt-oauth-bound-config-00.txt
Date: March 13, 2016 at 3:53:37 PM PDT
To: "Phil Hunt" mailto:phil.h...@yahoo.com>>, "Anthony 
Nadalin" mailto:tony...@microsoft.com>>, "Tony Nadalin" 
mailto:tony...@microsoft.com>>


A new version of I-D, draft-hunt-oauth-bound-config-00.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: draft-hunt-oauth-bound-config
Revision: 00
Title:   OAuth 2.0 Bound Configuration Lookup
Document date:  2016-03-13
Group: Individual Submission
Pages:  22
URL:
https://www.ietf.org/internet-drafts/draft-hu

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

[Anthony Nadalin]

This is not discovery, its simply metadata, it’s unclear if this is all the 
metadata that is needed  because discovery has not been fully thought out as 
apparent from all the exchanges that have been going on, I don’t understand the 
rush to get this document out when we already know it’s incomplete

There are still documents from Nat, and I believe there will be one from Phil 
and maybe others.

From: Mike Jones
Sent: Saturday, March 12, 2016 8:29 AM
To: Anthony Nadalin ; Brian Campbell 
; John Bradley 
Cc: oauth 
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The AS metadata format is a necessary part of discovery.  No, it doesn’t 
accomplish every possible aspect of discovery – nor was it ever intended to.  
I’ve consistently encouraged Phil and others to write down additional aspects 
of discovery in specifications that build upon this one so that the working 
group and implementers can evaluate them.

Since we’re chartered to do discovery and this is part of discovery, no 
rechartering is needed either for the current specification or for new 
specifications performing additional discovery tasks.

  -- Mike

From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Brian 
Campbell mailto:bcampb...@pingidentity.com>>; John 
Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin mailto:tony...@microsoft.com>>; 
Brian Campbell mailto:bcampb...@pingidentity.com>>; 
John Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
mailto:bcampb...@pingidentity.com>>; John Bradley 
mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d

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

[Anthony Nadalin]

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin ; Brian Campbell 
; John Bradley 
Cc: oauth 
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
mailto:bcampb...@pingidentity.com>>; John Bradley 
mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is 

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

[Anthony Nadalin]

Sorry but not true, this started out as “discovery” and now it’s not

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 11, 2016 3:59 PM
To: Anthony Nadalin 
Cc: John Bradley ; oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

That *is* the scope of the current document, which a majority of folks have 
agreed with. I was reiterating that the name of the document should reflect its 
content, something else that has been widely agreed with.

On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley mailto:ve7...@ve7jtb.com>>

Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is a optional AS meta-data 
discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol and not 
part of discovery that should remain optional.

I honestly don’t quite know how the client learns about this bad RS and starts 
talking to it, so this may be a solution to a problem that doesn’t yet exist.   
The one place this is posable is if the registration for the client is 
compromised.  However we are discussing other mitigations for that that also 
explicitly do not require discovery.

John B.


I am not stuck on webfinger or well-known. Because this is config maybe it 
should be an oauth endpoint.

Phil

On Mar 11, 2016, at 06:51, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I think Phil is proposing something different.   Should the client sen

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

[Anthony Nadalin]

so this is 
update that is consistent with the eisting architecture of OAuth 2.

Lets keep the two issues separate.

John B.




On Mar 11, 2016, at 12:07 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:

The relationship between AS and RS need to be scoped to “does this RS accept 
tokens from this AS” as a list is too much information that could be used in 
the wrong way

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Phil,

Right. So what my conditional approvals (11 conditions in total) said was to 
drop the word "discovery" from everywhere. This is not a discovery spec. This 
is a configuration lookup spec as you correctly points out. So, I am with you 
here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to 
express the AS-RS relationships. I have been preaching this in the other thread 
for so many times as you know so I thought I pointed it out, but missed 
apparently in my previous comment. So, I would add my 12th condition:

12. A way to express a list of valid RSs for this AS needs to be added to 
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>>:
I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
<mailto:roland.hedb...@umu.se>

wrote:



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 
mailto:hannes.tschofe...@gmx.net>

:



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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d>



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<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>

— Roland



”Everybody should be quiet near a little stream and listen."

>From ’Open House for Butterflies’ by Ruth Krauss





___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>






___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.

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

[Anthony Nadalin]

There have been way too many issues, confused conversations and discussions on 
and off list to have this document move forward, suggest that this be one of 
the main items on the agenda for when we meet.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, March 10, 2016 9:09 AM
To: Vladimir Dzhuvinov 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 


wrote:



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 
mailto:hannes.tschofe...@gmx.net>

:



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





___

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] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

The relationship between AS and RS need to be scoped to “does this RS accept 
tokens from this AS” as a list is too much information that could be used in 
the wrong way

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM) 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Phil,

Right. So what my conditional approvals (11 conditions in total) said was to 
drop the word "discovery" from everywhere. This is not a discovery spec. This 
is a configuration lookup spec as you correctly points out. So, I am with you 
here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to 
express the AS-RS relationships. I have been preaching this in the other thread 
for so many times as you know so I thought I pointed it out, but missed 
apparently in my previous comment. So, I would add my 12th condition:

12. A way to express a list of valid RSs for this AS needs to be added to 
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>>:
I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 


wrote:



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 
mailto:hannes.tschofe...@gmx.net>

:



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





___

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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

[Anthony Nadalin]

So as I understand it in the Link Relations repository are XML documents that 
one has to create, are you suggesting as part of this effort is to rewrite all 
that in JSON and make a proposal for that also ?

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Tuesday, February 16, 2016 4:55 PM
To: Anthony Nadalin ; oauth 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

Link relation is not at all XML. It is a step forward to RESTfulness.
In the older version of the draft, I was using JSONized version of it as well, 
but I splitted it out for the sake of brevity.
It is all about dynamic metadata about the response.
Once we do it with RFC5988, we could easily create a parallel to it with JSON 
meta object of your flavour.
(Currently, JSON schema seems to be in fashion, though I personally prefer HAL.)
Good things about using JSONized version is that it will be usable outside the 
HTTP and the fact that it can be stored in a single JSON object together with 
the data.
Bad thing about it is that we have to start from the syntax for it, which we 
can avoid by using RFC5988.
If people want the JSON version of this, I could do it as well.
However, since we are processing HTTP response headers anyways, there is not 
much compelling reason for that as long as we stick with HTTP.
That's why I am just sticking with RFC5988.

Nat.


2016年2月17日(水) 8:50 Anthony Nadalin 
mailto:tony...@microsoft.com>>:
I really think that this is a step backwards relative to technology and what 
the developers would accept. The Link Relations takes us back to the XML days, 
I thought we have all moved on from that and at least trying to move Oauth to 
JSON. I think if this were adopted we might be splitting the developers into 
folks that are already going down the current JSON path with Oauth and those 
that want to go back to XML.

This just seems a very odd draft to adopt this technology.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake mailto:n...@matake.jp>>, Nat Sakimura 
mailto:sakim...@gmail.com>>, Sascha Preibisch 
mailto:sascha.preibi...@gmail.com>>, Sascha 
Preibisch mailto:sascha.preibi...@gmail.com>>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d>
Status: 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKwM%3d>
Htmlized:   
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kh2nH4IyNm3OAA5nkrSFzZN16Xic%2b2EDUOfr%2fG6CjVY%3d>
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ICtk5U1e6kBPFI8ov0n06TAcqDX3HurgFTydXKD73Yo%3d>

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload i

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Anthony Nadalin]

Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin 
Cc:  
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Phil Hunt 
(IDM) mailto:phil.h...@oracle.com>>; Nat Sakimura 
mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; Nat 
Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
 is not a valid resource endpoint for 
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Anthony Nadalin]

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) ; Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com
 is not a valid resource endpoint for 
as.example.com
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS, the 
client will not send the token there as the authz server will say that is not 
the place the client may want to send the token to.

Nat

2016年2月24日(水) 23:59 Phil Hunt 
mailto:phil.h...@oracle.com>>:
Nat,

I’m not sure that having the resource server tell the client where its 
authorization server is secure by itself. The relationship between the 
Authorization Server and the Resource server need to be bound together in one 
of the discovery endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real 
resource server the current discovery spec will not lead the client to 
understand it has the wrong resource server. Rather the fake resource service 
will just have a fake discovery service. The hacker can now intercept resource 
payload as well as tokens because they were able to convince the client to use 
the legit authorization service but use the token against the hackers proxy.

The OAuth Discov

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Anthony Nadalin]

I hear that many folks don't want to add a mandatory crypto operation on the 
client side :-(

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, February 23, 2016 3:17 PM
To: Roland Hedberg 
Cc:  
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for 
Adoption

The idea of including the state in the PKCE calculation was one I think Hans 
brought up at the meeting in Darmstadt.

I think we discounted it as not solving the problem because the attacker could 
manipulate the code_challenge.

As and example the attacker receives the request and changes the code_challenge 
to one it makes up based on the state from a second request made to the client 
in it’s browser. 

The attacker can replay the token to the client with the state that will 
validate the code_callenge or use the token directly at the token endpoint to 
get a access token as it would know both the client secret and code verifier.

We moved on to look at another way to validate state by passing it to the token 
endpoint for validation to stop the cut and paste attack.

In thinking again about William and Nat’s question about why not PKCE, I looked 
at the idea of using PKCE again.

The problem with using PKCE as it is now is that we made the assumption that 
the attacker could not modify the request.

That got me trying to think of a way to:
 a) stop the attacker from modifying the request (signed request, probably too 
complicated to be generally deployed)
 b) allow the client to detect if code_challenge has been modified and abort of 
the request was compromise.

I realized that you could simply echo back the code_challenge from the 
authorization endpoint and that would allow the client to know if 
code_challenge had been altered in the request, assuming the attacker can’t 
modify the response from the legitimate AS.

So if we add that step we now have a client where code_challenge can’t be 
altered.  

That in it selfs stops the cut and pate attack.  It however still allows an 
attacker to use the code it receives along with the the code_verifier and 
client secret to get a AT and RT from the legitimate token endpoint.

So that is not enough Including state in the hash calculation helps against the 
cut and paste attack but we fixed that by returning code_challenge.

That leaves the other things we were talking about returning from the 
authorization endpoint.

If we include token_endpoint URI in the hash then any token the client requests 
thinking it is for the attackers token endpoint won’t generate the same 
code_challenge as the AS would based on it’s token endpoint.   The attacker 
would know the code_challenge and the real token endpoint URI but would have to 
generate a collision in the lifetime of code to use the code.   This would not 
be possible based on the PKCE analysis.

Returning the code_challenge and including the token_endpoint URI in the hash 
is the minimum needed for the code flow to stop both cut and paste as well  as 
protect the code from being used if stolen via a confused client attack.   It 
doesn’t stop the theft just the use of the token.  So it is mitigating the 
issue a different way from A and B that are trying to stop the attacker from 
getting the code.

Given the technique I realized it would be simple enough to also include some 
other paramaters in the hash
1) The authorization endpoint in the hash causing it not to validate if the 
client has been given a bad authorization endpoint so the client can modify the 
request.  
2) The client_id so that it cannot be tampered with in the request.
3) The state  This is tied to the browser instance for XSRF protection.  
Including this means it cannot be changed and is another protection against cut 
and paste.

Including all 4 in the hash may be overkill as they overlap in protection.  I 
however think that not integrity protecting one of the values might bite us in 
the future.

We could go farther and include scopes or the whole request but that gets more 
complicated than it is worth.  We do have a option for request signing already.

So we almost had this at the Darmstadt meeting but it slipped away.

This is not stoping the attack it is protecting code.   

I should point out that some of the attacks like man in the middling 
registration can still compromise the client secret, making it possible for an 
attacker to impersonate a client.

Nat’s option B doesn’t have a solution to that ether as far as I can tell.

I think the only option for that is to have a logical identifier for the AS and 
some sort of discovery check at registration to be certain that you are using 
the correct registration location.

Option A plus discovery works for that and mitigates confused client but not 
cut and paste.

We still have a problem with AT leaking.   I think that needs to be dealt with 
separately. 
Access tokens should have a audience (by value or by introspection) the client 
needs to te

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Anthony Nadalin]

I would go with option A, option B introduces concepts/syntax that complicates 
the current Oauth model

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Early February I posted a mail to the list to make progress on the solution to 
the OAuth Authorization Server Mix-Up problem discovered late last year.

Here is my mail about the Authorization Server Mix-Up:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15336.html&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DgIHvagw6YjaIFDFlxp4%2bhgQ7ivmV%2f2FuuuiDwVQRv8%3d

Here is my mail to the list that tries to summarize the discussion status and 
asked a few questions:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15697.html&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1EvoWm%2b7K2BSdvTGCDxmzBkmeSo3Wm1GWamgtG6fcNk%3d

Unfortunately, my mail didn't lead to the intended success. While there was 
some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that serves 
as a starting point for further work in the group*. We have two documents that 
provide similar functionality in an attempt to solve the Authorization Server 
Mix-Up problem.

So, here is the question for the group. Which document do you want as a 
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley

Link:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-mix-up-mitigation-01&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=l27GZP9%2bS5BgvlXxSsgJ2cZv66mFbRpdkREO5L%2bcjsQ%3d

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and Sascha 
Preibisch

Link:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bo6qJ%2b7JcAqfRCzAfD4D4oDCOF%2be29RFRLeyWtJP9lg%3d

Deadline for feedback is March, 4th.

Ciao
Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper 
acknowledgement for those who contributed to the work.

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

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[Anthony Nadalin]

Not sure about that. There are things that are "recommended" like the dynamic 
registration endpoint, I don't understand why this is recommended as a lot of 
folks still don't do this. There are security considerations about all the 
information that is in the discovery that have not been addressed.

-Original Message-
From: Mike Jones 
Sent: Thursday, February 18, 2016 10:18 AM
To: Anthony Nadalin ; Hannes Tschofenig 
; Phil Hunt ; John Bradley 

Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence

It's the OAuth-specific subset of what's already widely deployed.  Nothing was 
invented - just subsetted.

I think it's already as simple as possible unless the working group decides to 
remove even more functionality (which it can obviously do).

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, February 18, 2016 10:13 AM
To: Hannes Tschofenig ; Phil Hunt 
; John Bradley 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I also think we are way far from last call (and surprised to see last call 
issued) on this document as it is still very complex for something that should 
be very simple 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt ; John Bradley 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence



On 02/18/2016 03:06 PM, Phil Hunt wrote:
> BTW. I think we are FAR from Last Call on this topic.

Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to 
your message based on the claim from the authors that they believe the document 
is finished.

We will, of course, take all reviews into account and see where we are with the 
discovery spec. I, as the shepherd, will also do my review and I encourage many 
working group members to also take a look at the document and to provide their 
input.

Ciao
Hannes

___
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] OAuth Discovery spec pared down to its essence

[Anthony Nadalin]

I also think we are way far from last call (and surprised to see last call 
issued) on this document as it is still very complex for something that should 
be very simple 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt ; John Bradley 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence



On 02/18/2016 03:06 PM, Phil Hunt wrote:
> BTW. I think we are FAR from Last Call on this topic.

Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to 
your message based on the claim from the authors that they believe the document 
is finished.

We will, of course, take all reviews into account and see where we are with the 
discovery spec. I, as the shepherd, will also do my review and I encourage many 
working group members to also take a look at the document and to provide their 
input.

Ciao
Hannes

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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

[Anthony Nadalin]

I really think that this is a step backwards relative to technology and what 
the developers would accept. The Link Relations takes us back to the XML days, 
I thought we have all moved on from that and at least trying to move Oauth to 
JSON. I think if this were adopted we might be splitting the developers into 
folks that are already going down the current JSON path with Oauth and those 
that want to go back to XML.

This just seems a very odd draft to adopt this technology.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake mailto:n...@matake.jp>>, Nat Sakimura 
mailto:sakim...@gmail.com>>, Sascha Preibisch 
mailto:sascha.preibi...@gmail.com>>, Sascha 
Preibisch mailto:sascha.preibi...@gmail.com>>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:   
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload is, how it should be processed, and so on.  Since they
   are just additional response header/query parameters, any client that
   does not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to take the
   advantage of the extension.




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.

The IETF Secretariat
___
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

[Anthony Nadalin]

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 
mailto:sakim...@gmail.com>> wrote:

+1 for moving this forward.

2016年1月21日木曜日、John Bradleymailto:ve7...@ve7jtb.com>>さんは書きました:
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 embedded web views doesn't mention the new iOS 9 
SFSafariViewController which allows apps to display a system browser within the 
application. The new API doesn't give the calling application access to 
anything inside the browser, so it is acceptable for using with OAuth flows. I 
think it's important to mention this new capability for apps to leverage since 
it leads to a better user experience.

I'm sure that can be addressed in the coming months if this document is just 
the starting point.

I definitely agree that a document about native apps is necessary since the 
core leaves a lot of guessing room for an implementation.

For reference, 
https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26

And see the attached screenshot for an example of what it looks like.




Aaron Parecki
aaronparecki.com
@aaronpk


On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig 
>
 wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/

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 p

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

[Anthony Nadalin]

+1

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 6:30 PM
To: John Bradley ; Phil Hunt (IDM) 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption, this is important work.

On Thu, Jan 21, 2016, 9:48 AM John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
+1 for adoption

Mike and I are working on addressing the comments in a new draft for your 
reading pleasure shortly.

John B.

On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) 
mailto:phil.h...@oracle.com>> wrote:

+1 for adoption

+1 for Brian's comments

Phil

On Jan 20, 2016, at 14:42, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
I conditionally accept this document as a starting point for work in the OAuth 
working group on the assumption that the considerable simplifications discussed 
and accepted at 
http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html
 will be incorporated.
This document is (should be) intended to provide a mitigation to a security 
problem. As such, it would be nice to see it progress a little faster than the 
typical WG document. The more quickly the document can progress and/or be 
perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> 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
___
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] Call for adoption: OAuth 2.0 for Native Apps

[Anthony Nadalin]

After reading this draft I  think that this may be better off as an 
experimental draft and not a WG draft

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 19, 2016 3:47 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-wdenniss-oauth-native-apps%2f&data=01%7c01%7ctonynad%40microsoft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUhk%2fs%3d

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

Re: [OAUTH-WG] IETF 95 - Buenos Aires

[Anthony Nadalin]

I’m afraid that I would have to agree with Brian (hopefully this is not a trend)

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, January 15, 2016 9:16 AM
To: Hannes Tschofenig 
Cc: oauth@ietf.org; Rolando Martínez 
Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires

Speaking for myself but I suspect others might be in the same boat - I'd love 
to see some additional time beyond the official meeting made available to try 
and make more progress on the open work in OAuth. But the week before IETF in a 
different country (even if it's only a 19h bus ride) just isn't logistically 
feasible for me.

On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Summit on 
> Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc’d on this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meeting in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the upcoming
>> IETF meeting. Please drop me a private mail to tell me your plans.
>>
>> Ciao
>> Hannes
>>
>> ___
>> 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] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 1.1 
this will be the approach so it will be commonly used 

-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com] 
Sent: Wednesday, November 4, 2015 8:52 PM
To: Anthony Nadalin 
Cc: Justin Richer ;  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

OK, no good reason unless the client is using a HSM that can do HMAC and can 
export a symmetric key wrapped in a asymmetric key provided by the AS.

We don’t currently cover that use case of sending a wrapped symmetric key to 
the AS in POP key distribution.   
I don’t know how common that is going to be, but it is worth thinking about 
defining.

John B.

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware.
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

Our use case involves mostly hardware (TPM 1.2) based key generation, where the 
hardware (TPM 1.1) is slow we will use secure software execution environment, 
our use case is always client side generated keys

-Original Message-
From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Wednesday, November 4, 2015 8:48 PM
To: Anthony Nadalin 
Cc: John Bradley ;  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

That’s only if you’re using good hardware to produce a key. We can’t assume 
that’s the only kind of client that will exist, and software generation is 
likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. 
“If you client has a strong random generator function then you can make your 
own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware.
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way 
>>>>> <

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

Not sure why you think its weaker as it would be a wrapped key that the 
hardware produces 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, November 4, 2015 8:43 PM
To: Justin Richer 
Cc:  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

In the asymmetric case the use of a HSM or secure element is the argument for 
the client selecting the public key.   In those cases the client is doing the 
key gen in hardware so one hopes it is OK.   In the symetric case the client 
generating the key is weaker (as in I can’t think of any really good reason).


> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> 
> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
> we assume the server generates it in the normal case (issuer -> presenter). 
> Client generated token keys should be an exception, especially in the 
> asymmetric case.
> 
> — Justin
> 
>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> 
>> Agreed the only real difference is the quality of the key.  If the server 
>> generates it, then it knows that the client is not using the fixed hex value 
>> of DEADBEEF for everything.
>> 
>> John B.
>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>> wrote:
>>> 
>>> I agree that the effect is the same. From a security point of view 
>>> there is only an impact if one of the two parties is in a better 
>>> position to generate random numbers, which is the basis for 
>>> generating a high entropy symmetric key.
>>> 
>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
 Thanks for the detailed read, Brian.  You’re right that in the 
 symmetric case, either the issuer or the presenter can create the 
 symmetric PoP key and share it with the other party, since the effect is 
 equivalent.
 I suspect that both the key distribution draft and this draft 
 should be updated with a sentence or two saying that either 
 approach can be taken.  Do others concur?
 
 
 
  -- Mike
 
 
 
 *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
 *Sent:* Thursday, November 05, 2015 7:48 AM
 *To:* Mike Jones
 *Cc:* Kepeng Li; oauth@ietf.org
 *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
 JWTs spec addressing final shepherd comment
 
 
 
 +1 for the diagrams making the document more understandable.
 
 One little nit/question, step 1 in both Symmetric and Asymmetric 
 keys shows the Presenter sending the key to the Issuer. It's 
 possible, however, for the key to be sent the other way. Presenter 
 sending it to the Issuer is probably preferred for asymmetric, 
 especially if the client can secure the private keys in hardware. 
 But I don't know if one way or the other is clearly better for 
 symmetric case and PoP key distribution currently has it the other 
 way 
 .
 Should the intro text somehow mention the possibility that the 
 Issuer could create the key and send it to the Presenter?
 
 I know it's only the introduction but it was just something that 
 jumped out at me.
 
 
 
 
 
 On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
 mailto:michael.jo...@microsoft.com>> wrote:
 
 Thanks for suggesting the diagrams, Kepeng. They make the document 
 more understandable.
 
 -- Mike
 
 ---
 -
 
 *From: *Kepeng Li 
 *Sent: *‎11/‎5/‎2015 12:57 AM
 *To: *Mike Jones ; 
 oauth@ietf.org 
 *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
 addressing final shepherd comment
 
 Thank you Mike.
 
 
 
 The diagrams look good to me.
 
 
 
 Kind Regards
 
 Kepeng
 
 
 
 *发件人**: *Mike Jones >>> >
 *日期**: *Thursday, 5 November, 2015 12:32 am
 *至**: *"oauth@ietf.org " >>> >
 *抄送**: *Li Kepeng >>> >
 *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing 
 final shepherd comment
 
 
 
 Proof-of-Possession Key Semantics for JWTs draft -06 addresses the 
 remaining document shepherd comment – adding use case diagrams to 
 the introduction.
 
 
 
 The updated specification 

Re: [OAUTH-WG] confirmation model in proof-of-possession-02

[Anthony Nadalin]

I would rather just keep the "cnf" claim rather than flatten the structure 
since we are already using the "cnf" in production with the XBOX One. We are 
also using multiple conformation keys  and using the "cnf" claim makes it 
easier to have multiple confirmation keys (by just defining a new claim to hold 
each confirmation key, using the same structure as "cnf").

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Tuesday, August 11, 2015 3:00 PM
To: John Bradley 
Cc: oauth 
Subject: Re: [OAUTH-WG] confirmation model in proof-of-possession-02

On Tue, Aug 11, 2015 at 5:30 PM, John Bradley  wrote:
> I think Brian also argued that flattening would save a registry, and 
> be easier to process in the default case.
>
> I don’t really by the argument that having a cnf object makes it that 
> much harder to process.  I think it is stylistically better json to 
> keep the elements together so that they can be extended separately 
> from the main JWT claim space.
>
> Having two confirmation elements could be done flat but I think that 
> gets even more messy.
>
> I understand Brians arguments, however prefer having a cnf object with 
> no array.
>
> I have to agree with his observation that we should keep away from 
> promoting multiple confirmation elements as it adds to complexity and 
> interoperability issues.
> Better to make one work well and allow for an extension for those 
> cases that really need it.
>
> I think the SAML subject confirmation is too complex for most people 
> who use it to really understand all the combinations of options.

Thanks to all for the additional discussion/explanation.  If others want to 
weigh in, please do so.

Best regards,
Kathleen

>
> John B.
>
>
> On Aug 11, 2015, at 1:41 PM, Brian Campbell 
> 
> wrote:
>
> I took Nat's "+1" as support for flattening things into individual 
> claims like "cjwe", "cjwk" and "ckid". Maybe that's just confirmation 
> bias on my part. But it'd be interesting to get Nat's actual opinion 
> as apposed to his assumed or implied opinion. Nat?
>
> It seems to me that it's really a question of aesthetics because the 
> arguments in favor of the structured claim approach that cite 
> flexibility or the ability to "carry more than one conformation key or 
> key descriptor" are erroneous. Both approaches can carry more than one 
> as long as they are different types and both can achieve additional 
> flexibility by adding new names for things (all of which, I suspect, 
> will be very unlikely to happen anyway). My suggesting to flatten was 
> an attempt at simplification. And I do think it would simplify. But 
> that's only my opinion. If folks prefer the aesthetics and structure 
> of the "cnf" as currently defined and feel it's easier to comprehend, 
> I can live with that. All the rest of the justification, however, just 
> obscures things.
>
> To Kathleen's request, the thread index is 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ie
> tf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fthreads.html%2314854&d
> ata=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983c
> e7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=q4MCqdNwwxQ2WqZ1CAWABG
> IdUlDENFM0NvQ4SYEUMDY%3d and starts with 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14854.html.&data=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TGx59LZoSrJpLY0rrViJzO6KJnCTrqr%2bYy57NA9YH8E%3d
>  The consensus therein seems to be to leave things as they are (though only 
> John, Mike and I participated and I was the minority opinion).
>
>
>
>
>
> On Tue, Aug 11, 2015 at 7:29 AM, Mike Jones 
> 
> wrote:
>>
>> Brian's note contained two suggestions, which I'll address separately.
>>
>> The first was to have "cnf" contain an array of values rather than 
>> individual values.  But even he said "I'm not sure the extra 
>> complexity is worth it though. I've rarely, if ever, seen SAML 
>> assertions that make use of it."  I took Nat's +1 as an agreement 
>> that the complexity of array values isn't worth it, and shouldn't be 
>> introduced.  No one else has since spoke up for having the "cnf" 
>> claim contain array values, and Brian only mentioned it as a possibility but 
>> dismissed it as too complex.
>>
>> The second was to not have the "cnf" claim at all, but instead to 
>> flatten things so that the "cnf" elements would become individual 
>> claims, along the lines of "cnf_jwk", "cnf_jwe", "cnf_kid", etc.  
>> This was discussed in the thread " [OAUTH-WG] JWT PoP Key Semantics WGLC 
>> followup 3 (was Re:
>> confirmation model in proof-of-possession-02)" - for instance, John 
>> Bradley's message 
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.i
>> etf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14859.html&data=0
>> 1%7c01%7ctonynad%40micros

Re: [OAUTH-WG] Use of Token Exchange spec for API Federation

[Anthony Nadalin]

So in your scenario where you have client (c), user (u), resource (r) and 
resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG ; Mike Jones 
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

We're examining the use of the Token Exchange spec for API federation 
use-cases, and are looking for some feedback.

The basic use-case is as follows:  Developer wants to build an Application that 
is a composite of backend services that span multiple security domains.   For 
example, it's a combination of Salesforce data and their own backend services.  
   The application is authenticated by Salesforce, and developer wants to 
exchange our ID Token for a token in the second security domain so that login / 
credentials are not required for the second back-end service.

To do this, we're planning to add configuration for multiple audiences in our 
service, allowing the developer to receive a mutli-party ID Token.   We may 
also add custom claims to facilitate mapping of identity across the services.   
Having logged into Salesforce, and received an ID Token, the developer would 
then call a Token Exchange service in the second security domain and exchange 
this ID token for a token specific to that domain.   This allows for simple API 
federation use-cases without converging both APIs / backends on a common token 
format.

Questions / Feedback

1) In the spec, "sub" is a required field.   However, the application may not 
yet know who the subject is in the second security domain ( it first has to 
exchange the token )One option might be to place the client_id of the 
application as issued by the second security domain, but that seems a bit off.  
 Any advice?   Should this be an Optional field?

2) Speaking of client_ids, if we don't use the "sub" to transport them, we 
believe the second security domain would still appreciate this context.   The 
Actor field is available, but construction of a full JWT just to transport the 
client_id seems like high overhead, and it may not even be aligned with the 
intent of that field.Should client_id be a claim here?

3) Speaking of Actors, It's not clear what actually states that the jwt 
included in the token is actually an approved actor.Is it intended that the 
act_as or on-behalf_of tokens include an azp authorized party clam as well?

4) "Implementations of the specification MUST implement support for using JWTs 
as the Security Tokens.  Other Security Token types MAY be supported."   This 
seems antithetical to the purpose of an STS.   We believe this should be 
relaxed to a SHOULD

Thanks for any feedback here





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

Re: [OAUTH-WG] Token Chaining Use Case

[Anthony Nadalin]

I’m not sure how Brian’s approach solves the basic generic token exchange use 
case that we have

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 7, 2015 4:47 PM
To: Mike Jones 
Cc:  
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This approach is not a good fit for my use cases, and it’s still not  OAuth-y 
at all. It requires a specially-formed security assertion on the way in, which 
the client must understand and generate. I still can’t take an arbitrary token 
I’ve been handed by someone else and pass it off to be pushed forward. The new 
“*_type” parameters seem to merely kick the can down the road instead of 
addressing the problems with the current specification.

I think that Brian’s approach works much better. It unrolls important 
parameters, properly uses the token endpoint, and allows for arbitrarily 
formatted input tokens.

When combined with Nat’s draft that specifies how to perform all generic OAuth 
requests as JWTs (or even some of the upcoming PoP work if we ever do that), 
you’ve pretty much got the draft below but with much more flexibility and power.

 — Justin

On Jul 7, 2015, at 6:51 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

As just updated, I believe that the working 
group token exchange draft 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also 
serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token 
chaining use case, as well as support general token exchange, including 
exchange of JWT and SAML tokens.  The mechanism would be the same one that 
Brian suggested below – defining security token type values for OAuth 2.0 
access tokens and refresh tokens – enabling them to be used as inputs and 
outputs in any of the token exchanges.

For instance, by using “access token” as the input security token type, 
providing new scope values, and using “access token” as the output security 
token type, token chaining is achieved.

Now, a question for the working group…  What should the security token type 
values for access token and refresh token be?  Two different choices seem to 
make sense.
(1)  Use the values “access_token” and “refresh_token”, which are used in RFC 
6749 token response values.
(2)  Define new URNs for this usage, such as 
urn:ietf:params:oauth:token-type:access-token and 
urn:ietf:params:oauth:token-type:refresh-token.

I’d personally be fine just using the short names in (1).

If people agree with this approach, we can document this usage in the -03 draft 
and publish it as soon as the submission tool reopens Monday morning during 
IETF 93.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This kind of token exchange might involve exchanges other than swapping an AT 
for another AT (and downscoping it). It might be an AT for a structured JWT 
specifically targeted at one of the the particular services that the original 
RS needs to call. Or an AT might be exchanged for a SAML assertion to use with 
legacy SOAP serveries.  A good general token exchange mechanism enables lots of 
variations of cases like the one Justin mentioned. And more. In fact, I think 
downscoping might be a minority use case where what token exchange is often 
need for is translating tokens from what you have into what the resource you 
need to call can deal with.
There need to be ways for the caller to tell the AS about the token it's asking 
for - by type or by the address/identifier of where it'll be used. There needs 
to be ways for the caller to authenticate to the AS. And there needs to be some 
way of expressing this delegation thing (though I'm still not totally convinced 
it couldn't be just the token is about the user/principal and the caller/client 
of the exchange is who is being delegated to).
I realize few (approaching zero) people have or are going to read it but I have 
endeavored to cover all these things in the 
http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an early 
draft so not without it some rough edges but can provide some guidance on what 
is needed and offers some protocol syntax for expressing it. I believe Justin's 
use case would be covered by it (defining a specific token type URI for an 
OAuth access token issued by the AS in question might be needed) as are many 
others.

On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:
As requested after last night’s informal meeting, here is the token chaining 
use case that I want to see represented in the token swap draft.


[ Client ]  ->   [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, with 
scopes [A, B, C] in order to call service A, which requires all three sc

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

What is written in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and 
the text that describes the Windows Kerberos support for Protocol Transition 
and Constrained Delegation are in alignment not sure what make you think they 
are not.

If you are trying to describe different features than Windows Kerberos Protocol 
Transition/Constrained Delegation that then I would agree that the text may not 
be correct but then again it would not be describing the Windows Kerberos 
Protocol Transition/Constrained Delegation. The way you have the text describes 
different set use case then what the feature of  
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
describes.

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, July 6, 2015 2:33 PM
To: Anthony Nadalin 
Cc: Mike Jones ; oauth 
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

A natural usage of act-as or 
impersonation<http://www.oxforddictionaries.com/us/definition/american_english/impersonate>
 would suggest, to many people anyway, that the way you just used the terms is 
reversed. The bold text below from 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 
'impersonates' and "on-behalf-of" contrary to what you just wrote about Windows 
Kerb. That's where the assertion that the draft has them reversed from de facto 
usage in WS-Trust. Those semantics are not only one open issue that needs to be 
resolved, however, even if they occupy most of the discussion.

1.3.  On-Behalf-Of vs. Impersonation Semantics

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, with
   on-behalf-of semantics, principal A still has its own identity
   separate from B and it is explicitly understood that while B may have
   delegated its rights to A, any actions taken are being taken by A and
   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  When principal A
   impersonates principal B, then in so far as any entity receiving
   Claims is concerned, they are actually dealing with B. It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.





On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition 
(impersonation)  feature as this enables an account to impersonate another 
account for the purpose of providing access to resources. In a typical 
scenario, the impersonating account would be a service account assigned to a 
web application or the computer account of a web server. The impersonated 
account would be a user account requiring access to resources (e.g. data in an 
SQL database) via a web application. In this scenario, SQL server would be 
accessed by the impersonating (service account) account, however access would 
be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
feature, which lets you limit the back-end services for which a front-end 
service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
selected services on a server can be granted for access by the impersonating 
account, whilst other services on the same server, or services on other servers 
are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in 
WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear 
explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and 
Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: oauth mailto:oauth@ietf.org>>

Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Stating specific action items resulting from the ad-hoc meeting in Dallas like 
that suggests some clear consensus was reached, which is not at all the case. 
As I recall, several of us argued past one another for an hour or so and 
decided to adjourn in order to go to the bar (okay, and dinner too - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN link<https://msdn.microsoft.com/en-us/library/ee748487.aspx> 
John gave is much 

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition 
(impersonation)  feature as this enables an account to impersonate another 
account for the purpose of providing access to resources. In a typical 
scenario, the impersonating account would be a service account assigned to a 
web application or the computer account of a web server. The impersonated 
account would be a user account requiring access to resources (e.g. data in an 
SQL database) via a web application. In this scenario, SQL server would be 
accessed by the impersonating (service account) account, however access would 
be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
feature, which lets you limit the back-end services for which a front-end 
service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
selected services on a server can be granted for access by the impersonating 
account, whilst other services on the same server, or services on other servers 
are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in 
WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear 
explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and 
Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones 
Cc: oauth 
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Stating specific action items resulting from the ad-hoc meeting in Dallas like 
that suggests some clear consensus was reached, which is not at all the case. 
As I recall, several of us argued past one another for an hour or so and 
decided to adjourn in order to go to the bar (okay, and dinner too - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN link 
John gave is much more to the point than WS-Trust (I don't believe WS-Trust can 
be pointed to as a model of clarity).  In the draft I wrote, I tried to take 
Mike's text and clarify a distinction between impersonation and delegation with 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then 
also be very explicit about act-as vs. on-behalf-of in the parameter 
definitions at 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor 
that was consistent with WS-Trust and the MSDN explanation. I could see value 
in breaking with that shaky legacy and using new terms too. But I get the point 
of trying to keep with the old also and potential for even more confusing by 
using new terms.
I wrote draft-campbell-oauth-sts last year in response to the call for adoption 
of jones-oauth-token-exchange (thread from the 
archive). 
Though I didn't try and stand in the way and indicated a willingness to 
collaborate on things. With the expectation, of course, that the details would 
differ from the -00s and -01s as work progressed. Folks seemed generally 
amenable to 
that at the 
time but little has happened since then.
Phil's earlier point about the priory of this getting pushed down has some 
truth to it. But I still believe it's something that can provide a lot of value 
in standardizing, if we do so in a reasonable way.





On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
It would surprise me if on-behalf-of and act-as were reversed with respect 
WS-Trust, because the explanations of the terms came directly from WS-Trust 
1.4.  I also think the chances of us reducing confusion by inventing new 
terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in 
Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and 
on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - 
allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done 
today before the submission cutoff.  I agree with John that it would be useful 
to have discussions on this in Prague on the best way to achieve this further 
integration.  I'll plan to come into the Prague meeting with a concrete 
proposal for review.

Best wishes,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@i

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

Not quite, the actual tokens are still opaque, the requestor is just asking for 
a token exchange , the requestor can specify the requested token type it's up 
to the server to determine the actual token it will delever

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, July 1, 2015 5:18 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

As it's written right now, it's a translation of some WS-* concepts into JWT 
format. It's not really OAuth-y (since the client has to understand the token 
format along with everyone else, and according to the authors the artifacts 
might not even be "OAuth tokens"), and that's my main issue with the document. 
Years ago, I proposed an OAuth-based token swap
mechanism:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

This works without defining semantics of the tokens themselves, just like the 
rest of OAuth. I've proposed to the authors of the current draft that it should 
incorporate both semantic (using JWT) and syntactic (using a simple 
token-agnostic grant) token swap mechanisms, and that the two could be easily 
compatible.

  -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
> Hmm... perhaps the clue is in the draft title, token-exchange, so may 
> be it is a case of the given access token ("on_behalf_of" or "act_as"
> claim) being used to request a new security token. One can only guess 
> though, does not seem like the authors are keen to answer the newbie 
> questions...
>
> Cheers, Sergey
>
>
> On 30/06/15 13:38, Sergey Beryozkin wrote:
>> Hi,
>> Can you please explain what is the difference between On-Behalf-Of 
>> semantics described in the draft-ietf-oauth-token-exchange-01 and the 
>> implicit On-Behalf-Of semantics a client OAuth2 token possesses ?
>>
>> For example, draft-ietf-oauth-token-exchange-01 mentions:
>>
>> "Whereas, with on-behalf-of semantics, principal A still has its own 
>> identity separate from B and it is explicitly understood that while B 
>> may have delegated its rights to A, any actions taken are being taken 
>> by A and not B. In a sense, A is an agent for B."
>>
>> This is a typical case with the authorization code flow where a 
>> client application acts on-behalf-of the user who authorized this 
>> application ?
>>
>> Sorry if I'm missing something
>>
>> Cheers, Sergey
>> On 25/06/15 22:28, Mike Jones wrote:
>>> That's what
>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is 
>>> about.
>>>
>>> Cheers,
>>>
>>> -- Mike
>>>
>>> *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek 
>>> Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)
>>> *Sent:* Thursday, June 25, 2015 2:20 PM
>>> *To:* OAuth@ietf.org
>>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case
>>>
>>> Hi All,
>>>
>>>I am looking to solve a use-case similar to WS-Security 
>>> On-Behalf-Of 
>>> >> -1.4-errata01-os-complete.html#_Toc325658980>
>>>
>>>
>>> with OAuth JWT Token.
>>>
>>>Is there a standard claim which we can define within the OAuth 
>>> JWT which denote the On-behalf-of User.
>>>
>>> For e.g., a Customer Representative trying to create token on behalf 
>>> of a customer and trying to execute services specific for that 
>>> specific customer.
>>>
>>> Regards,
>>>
>>> Vivek Biswas,
>>> CISSP
>>>
>>> *Cisco Systems, Inc *
>>>
>>> *Bldg. J, San Jose, USA,*
>>>
>>> *Phone: +1 408 527 9176*
>>>
>>>
>>>
>>> ___
>>> 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] JWT Destination Claim

[Anthony Nadalin]

There some folks out there that are using AUD to mean DST. Adding DST is 
confusing, if you want to use it that's fine but don't see a need to 
standardize every claim that someone comes up with

Sent from my Windows Phone

From: Brian Campbell
Sent: ‎3/‎25/‎2015 2:19 PM
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Destination Claim

FWIW, I did have that as an open issue in the draft: 
http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A

Though the way I worded it probably shows my bias.

On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Thanks for posting this, Brian.  To get it down on the list, I’ll repeat my 
comment made in person that just as “aud” used to be single-valued and ended up 
being multi-valued, I suspect some applications would require the same thing of 
“dst” – at least when “aud” and “dst” are different.  And even if “dst” becomes 
multi-valued, it’s OK for particular applications to require that it be 
single-valued in their usage.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of Brian Campbell
Sent: Wednesday, March 25, 2015 2:08 PM
To: oauth
Subject: [OAUTH-WG] JWT Destination Claim

Here are the slides that I rushed though at the end of the Dallas meeting:
https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf

And the -00 draft:
http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00
In an informal discussion earlier this week John B. suggested that some 
additional thinking and/or clarification is needed with regard to what parts of 
the URI to include and check. Particularly with respect to query and fragment. 
And he's probably right.

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

[OAUTH-WG] Token Introspection: Misc Review Comments

[Anthony Nadalin]

Some comments:

> The endpoint MAY allow other parameters to provide further context to the 
> query.

If the endpoint does not understand these the endpoint must ignore.

The only MUST in this specification is to return the "active" Boolean, but this 
is still underspecified as there is no definition or criteria that a developer 
has to go upon to determine if that Boolean is set or not.

token_type_hint  is really not a type hint but just a token hint and thus 
should be chnaged

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

Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

[Anthony Nadalin]

This can't be limited to JWE Compact Serialization, we have keys that use the 
JSON binary serialization.

"cnf" seems underspecified, as this could be a JWK (but not it's not a MUST), 
and thus I may understand "cnf" but only when used with a JWK and not some 
other invented structure. So how do I tell what "cnf" really is ?

Is this proposal also limited to a single key  for both asymmetric and 
symmetric  ?

-Original Message-
From: Mike Jones 
Sent: Wednesday, March 4, 2015 3:34 PM
To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

It does so for the same reason that the JWT spec does - to promote 
interoperability.  We can add wording along the likes of "the JWE Compact 
Serialization MUST be used" if you like.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Wednesday, March 04, 2015 3:26 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

Why does the specification state "encrypted to a key known to the recipient 
using the JWE Compact Serialization" is this the only serialization allowed 
(there is no MUST) ?
containing the symmetric key.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

Hi all,

as the deadline is approaching I would like to close the open issues of the 
document. There are two open issues listed in the document and I propose ways 
to resolve them below

Open Issue #1:

"In some conversations, we have said that it is the issuer of the JWT
   that possesses the key, and in some conversations, we have said that
   it is the presenter of the JWT that possesses the key.  Which
   description should we use?
"

There are the following parties in the entire picture (as the PoP architecture 
document illustrates quite nicely):

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key
cryptography) to a recipient.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

Mapping this terminology to the OAuth context would look as follows:
 - Issuer: OAuth Authorization Server
 - Presenter: OAuth Client
 - Recipient: OAuth Resource Server

Adding the above-mentioned terminology to the terminology section (and deleting 
the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

Mike added an editorial note to the introduction saying:
"
 [[ Editorial Note: This paragraph needs to be updated to provide more
   context and possibly also to describe the use of asymmetric keys
   instead.  It's not clear that the symmetric case is as useful or
   valuable, and it is certainly more complicated.]] "

The design team work clearly indicated that both symmetric and asymmetric 
cryptography has to be supported. The JWT mechanism actually supports both and 
hence we should also describe both. What can, however, be done is to also 
describe the asymmetric key case and here is my text proposal for the 
introduction.


1.  Introduction

   This specification defines how to bind a key to a JSON Web
   Token (JWT) [JWT]. Three parties act in such a scenario:

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key cryptography) to 
a recipient. This property is also sometimes described as the presenter being a 
holder-of-key.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

[I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession 
semantics for JSON Web Tokens (JWTs) for the use with OAuth.

   Envision the following two use cases. The first use case describes
   the use of a symmetric key and the second use case focuses on
   asymmetric cryptography.

   An OAuth 2.0 authorization server generates a JWT
   and places an encrypted sy

Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

[Anthony Nadalin]

Why does the specification state "encrypted to a key known to the recipient 
using the JWE Compact Serialization" is this the only serialization allowed 
(there is no MUST) ?
containing the symmetric key.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

Hi all,

as the deadline is approaching I would like to close the open issues of the 
document. There are two open issues listed in the document and I propose ways 
to resolve them below

Open Issue #1:

"In some conversations, we have said that it is the issuer of the JWT
   that possesses the key, and in some conversations, we have said that
   it is the presenter of the JWT that possesses the key.  Which
   description should we use?
"

There are the following parties in the entire picture (as the PoP architecture 
document illustrates quite nicely):

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key
cryptography) to a recipient.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

Mapping this terminology to the OAuth context would look as follows:
 - Issuer: OAuth Authorization Server
 - Presenter: OAuth Client
 - Recipient: OAuth Resource Server

Adding the above-mentioned terminology to the terminology section (and deleting 
the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

Mike added an editorial note to the introduction saying:
"
 [[ Editorial Note: This paragraph needs to be updated to provide more
   context and possibly also to describe the use of asymmetric keys
   instead.  It's not clear that the symmetric case is as useful or
   valuable, and it is certainly more complicated.]] "

The design team work clearly indicated that both symmetric and asymmetric 
cryptography has to be supported. The JWT mechanism actually supports both and 
hence we should also describe both. What can, however, be done is to also 
describe the asymmetric key case and here is my text proposal for the 
introduction.


1.  Introduction

   This specification defines how to bind a key to a JSON Web
   Token (JWT) [JWT]. Three parties act in such a scenario:

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key cryptography) to 
a recipient. This property is also sometimes described as the presenter being a 
holder-of-key.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

[I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession 
semantics for JSON Web Tokens (JWTs) for the use with OAuth.

   Envision the following two use cases. The first use case describes
   the use of a symmetric key and the second use case focuses on
   asymmetric cryptography.

   An OAuth 2.0 authorization server generates a JWT
   and places an encrypted symmetric key inside the newly introduced
   confirmation claim.  This symmetric key is encrypted with a key known
   only to the authorization server and the recipient. The entire JWT
   is then integrity protected.  The JWT is then sent to the
   presenter.  Since the presenter is unable to obtain the
   encrypted symmetric key from the JWT itself, the authorization
   server conveys that symmetric key separately to the presenter.  Now,
   the presenter is in possession of the symmetric key as well as the
   JWT (which includes the confirmation claim member).  When the
   presenter needs to present the JWT to the recipient, it also needs
   to demonstrate possession of the symmetric key; the presenter, for
   example, uses the symmetric key in a challenge/response protocol
   with the recipient.  The recipient is able to verify that it is
   interacting with the genuine presenter by decrypting the JWK
   contained inside the confirmation claim of the JWT.  By doing this
   the recipient obtains the symmetric key, which it then uses to
   verify cryptographically protected messages exchanged with the
   presenter.

   This symmetric key mechanism described above is conceptually similar
   to the use of Kerberos tickets.

   In the second case consi

Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

[Anthony Nadalin]

>The definition of “active” is really up to the authorization server, and I’ve 
>yet to hear from an actual implementor who’s confused by this definition. When 
>you’re the one issuing the tokens, you know what an “active” token means to you

According to the spec as written the Introspection endpoint does not have to be 
an Authorization Sever and thus each could have defined “active” in different 
ways

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 4, 2015 1:46 PM
To: Hannes Tschofenig
Cc: 
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

Hi Hannes, thanks for the feedback. Responses inline.

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

We’ve already done this in the latest draft. Or at least, that’s the intent of 
the current text — the registry is referenced and the new claims are 
registered. Can you specifically point to places where this needs to be 
improved upon?


Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
 REQUIRED.  Boolean indicator of whether or not the presented token
 is currently active.  The authorization server determines whether
 and when a given token is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

The definition of “active” is really up to the authorization server, and I’ve 
yet to hear from an actual implementor who’s confused by this definition. When 
you’re the one issuing the tokens, you know what an “active” token means to 
you. Still, perhaps we can be even more explicit, such as:


active
  REQUIRED. Boolean indicator of whether or not the presented token is 
currently active. The specifics of a token’s active state will vary depending 
on the implementation of the authorization server, but generally this will 
indicate that a given token has been issued by this authorization server, has 
not been revoked by the resource owner, and is within its given time window of 
validity (e.g. not expired).

Also, this is one of the places where the overlap between JWT and introspection 
claims don’t make sense. It doesn’t make any sense for a JWT to carry an 
“active” claim at all. Why would you have a JWT claim to be anything but 
active? We should register it with the JWT registry to avoid name collisions, 
but there’s nothing in the JWT registry that says “don’t use this inside of a 
JWT”. Do you have any advice on how to address this?



client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

Whatever it wants to. If an RS can figure out something from the client_id, why 
not let it? The client_id is a piece of information about the context of the 
issuance of the token, and a common enough OAuth value for decision making.


I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

This isn’t any different from having a userinfo-endpoint equivalent (like 
social graph or twitter API) and it’s got the same trouble.



 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

We added in “user_id” to our implementation due to developer demand — they 
wanted a username associated with the return value, but to leave the “sub” 
value the same as that defined by OpenID Connect. Note that this is in a

Re: [OAUTH-WG] draft-ietf-oauth-introspection

[Anthony Nadalin]

1.   Answer is still unclear, Is the metadata (introspection response) 
being returned from the authorization endpoint or from the token or a 
combination of both ? The answer needs to go in the spec

2.   Spec needs to contain this information about stateless tokens

3.   For interoperability there needs to be an understanding of what token 
types this specification supports, we already know some token types that may 
not work

4.   I'm not issuing an Oauth encrypted token as it's just a bearer token, 
just happens to be a an encrypted SAML token, which I don't know since I'm a 
client that can't understand what is in token

5.   I would propose wording but I'm still trying to figure out what 
"active" means so that everyone implementing this has the same understanding, I 
did not see a definition of active in the specification.

What about the Audience restricted tokens, do you expect the endpoint to ignore 
this and process the tokens for metadata ?

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Monday, December 1, 2014 4:42 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection


1.   Is the metadata (introspection response) being returned from the 
authorization endpoint or from the token or a combination of both ?

As I said below, ultimately it's about the token and what it represents. If the 
token was issued through use of the authorization endpoint, then it's likely 
that there's some context from that authorization endpoint tied to the token 
that can be returned.



2.   "context" there may be no context other than the token, are you 
expecting the authorization endpoint to always keep a context of how/why the 
token was issued ?

If you're asking if stateless tokens can be supported with this, then yes, 
that's fine. If the token's completely on its own (like a structured token 
generated as an assertion and used as an OAuth 2.0 access token) and a server's 
able to unpack that for a client without access to other pieces of context, 
then that's what it returns. But in that case, if you're issuing stateless 
tokens, with self-contained metadata and expirations and no other context to be 
conveyed beyond what's already inside the token, then you'd probably just tell 
your protected resources how to parse and handle them directly.



3.   The specification should clearly state which type of tokens are 
supported and what profiles/bindings are supported, like JWT Bearer, etc.

That's opaque to the protected resource for purposes of this protocol, just 
like a token is opaque to a client for purposes of 6749/6750 OAuth. The 
introspection protocol supports whatever tokens are supported by the AS, so we 
don't need to list token types, but maybe we can be clearer about the 
opaqueness of the token value in this process. Since these are OAuth tokens and 
not assertions, no bindings or profiles are needed beyond this. It's a simple 
query-response and it's up to the server to know how to fulfill this contract.



4.   If I have an SAML Bearer assertion, and the SAML assertion is 
encrypted and have no way to know this, it can potentially fail if it can't be 
decrypted but as far as I can tell I'm not sending an encrypted token since 
this is just a SAML assertion, not sure how one really determines what is wrong

If the AS can't decrypt the token then it can't introspect it. So it doesn't in 
this case. And if you're issuing encrypted OAuth tokens with no means to 
decrypt them back at the AS, then you probably wouldn't offer an introspection 
service to begin with. This is covered in the security considerations section 
already.



5.   Should be spelled out what "active" is supposed to mean so folks get 
the same results on different endpoints

As I said below, it means to answer "is this token still good or not?" for a 
protected resource that can't answer that on its own, and I believe the current 
definition reflects that. Please submit text if the existing definition is 
insufficient or unclear to you.

 - Justin





From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

Tony, thanks for the comments. Your timing is great, as I was just today 
sitting down to polish the introspection draft into a proper WG document ready 
for the last-call tomorrow. I've just posted the updated draft, and I think 
that you'll find it addresses your concerns. More direct answers inline:


On Nov 30, 2014, at 1:01 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:



Comments

Intro
"about the authentication conext", not sure what this is since there is no 
au

Re: [OAUTH-WG] draft-ietf-oauth-introspection

[Anthony Nadalin]

Thanks for the update, there are still some unclear points


1.   Is the metadata (introspection response) being returned from the 
authorization endpoint or from the token or a combination of both ?

2.   "context" there may be no context other than the token, are you 
expecting the authorization endpoint to always keep a context of how/why the 
token was issued ?

3.   The specification should clearly state which type of tokens are 
supported and what profiles/bindings are supported, like JWT Bearer, etc.

4.   If I have an SAML Bearer assertion, and the SAML assertion is 
encrypted and have no way to know this, it can potentially fail if it can't be 
decrypted but as far as I can tell I'm not sending an encrypted token since 
this is just a SAML assertion, not sure how one really determines what is wrong

5.   Should be spelled out what "active" is supposed to mean so folks get 
the same results on different endpoints



From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

Tony, thanks for the comments. Your timing is great, as I was just today 
sitting down to polish the introspection draft into a proper WG document ready 
for the last-call tomorrow. I've just posted the updated draft, and I think 
that you'll find it addresses your concerns. More direct answers inline:


On Nov 30, 2014, at 1:01 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:


Comments

Intro
"about the authentication conext", not sure what this is since there is no 
authentication context in Oauth

There are several authentication contexts in OAuth: the resource owner at the 
authorization endpoint, the client at the token endpoint, etc. Regardless, this 
is meant to be the context of the authorization decision, text now reads: 
"context in which the token was issued"


Use of Oauth2, mixed with use of Oauth, pick one

All usage changed to "OAuth 2.0" throughout the document, let me know if I 
missed any.


"allows holder of a token to query" so anything/anyone that has a token can use 
this endpoint?

Now reads authorized holder of the token and has stronger language and 
recommendations about requiring authorization on the endpoint to prevent public 
token fishing. This was already addressed in the security considerations 
section, but that has been propagated throughout the specification now.



Introspection Endpoint
Use of Oauth2, mixed with use of Oauth, pick one


See above.



Introspection Request
The endpoint SHOULD also require some form of authentication", what about some 
form of authorization ? Why do we have to have another endpoint that we have to 
manage and then have a management API draft?]

This is now clearer that it needs to be an authorized protected resource. This 
authorization may be carried through a credential mechanism as defined in OAuth 
2.0, through an access token, or through some other mechanism.



Token - is this any type of token ? how does the endpoint know that it can deal 
with this token type?

Clarified that it's either the access_token from the token endpoint or the 
refresh_token from the token endpoint. You can use this with other token types, 
but that's not defined in this spec which concerns itself with RFC6749/RFC6750.


So endpoint has to try to lookup token  to determine if it can maybe find out 
something about the token?

That's the idea, the protected resource is asking an authoritative source (the 
authorization server) about a given token. I had always thought it was obvious 
that the authorization server would have to be able to know something about the 
token in order to provide an introspection service, but since that seems to 
have been unclear to some I've made it explicit in the security considerations 
section.


Can the one use the authorization code or does one have to get a token first?

No, this is for tokens only. I don't see the point of introspecting an 
authorization code - those aren't sent to protected resources, they're sent to 
clients, which would in turn just hand it to the token endpoint to get a token. 
There's nothing else to find out about it.


 Can I send a encrypted token and expect a proper response ?

If the server can decrypt or otherwise understand the token, yes. I've pointed 
out this requirement in the security considerations section.


What about a Proof of Possession Token?

Yes, I think this fits great with PoP tokens, but those aren't defined well 
enough yet to say anything concrete. As the PoP work progresses, we can have an 
extension document to determine what needs to be done there. Note that we'll 
have to do the same thing with the Revocation RFC.


 Introspection Response
What is "active" mean ? Is this up to the server t

[OAUTH-WG] draft-ietf-oauth-introspection

[Anthony Nadalin]

Comments

Intro
"about the authentication conext", not sure what this is since there is no 
authentication context in Oauth
Use of Oauth2, mixed with use of Oauth, pick one
"allows holder of a token to query" so anything/anyone that has a token can use 
this endpoint?

Introspection Endpoint
Use of Oauth2, mixed with use of Oauth, pick one

Introspection Request
The endpoint SHOULD also require some form of authentication", what about some 
form of authorization ? Why do we have to have another endpoint that we have to 
manage and then have a management API draft?]

Token - is this any type of token ? how does the endpoint know that it can deal 
with this token type? So endpoint has to try to lookup token  to determine if 
it can maybe find out something about the token? Can the one use the 
authorization code or does one have to get a token first?

Can I send a encrypted token and expect a proper response ? What about a Proof 
of Possession Token?

Introspection Response
What is "active" mean ? Is this up to the server to determine ?
"scope OPTIONAL", is this the scope in the token or is this the scope that the 
introspection endpoint sources may have ? It's unclear if all these return 
values are from the token or from the introspection endpoint sources ?
What error codes/conditions are there? Just the 400  (bad request)?
Can the endpoint return a encrypted response ?
What about PII such as user_id, aud ?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

Same here

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, October 16, 2014 10:17 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

For what it's worth, I was on the call too - until I and Brian left to join the 
telechat for the OAuth assertions drafts.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, October 16, 2014 9:55 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

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

Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?

[Anthony Nadalin]

Add me

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the 
draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to 
discuss the problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational 
document.

Conference calls could start in about 2 weeks and we would like to know who 
would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

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

Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

[Anthony Nadalin]

I don't see it that way as the guidelines not clear and we should revisit this 
since there was no conclusion in Toronto. 

-Original Message-
From: Richer, Justin P. [mailto:jric...@mitre.org] 
Sent: Thursday, September 11, 2014 8:01 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next 
Steps?

According to the guidelines here:

https://www.ietf.org/iesg/informational-vs-experimental.html

And the discussion in Toronto, it's clearly experimental.

 -- Justin

On Sep 11, 2014, at 10:36 AM, Anthony Nadalin  wrote:

> Is "experimental" the correct classification? Maybe "informational" is more 
> appropriate as both of these were discussed. 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, September 10, 2014 4:50 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next 
> Steps?
> 
> Hi all,
> 
> in response to the discussions at the last IETF meeting the authors of the 
> "Dynamic Client Registration Management Protocol"
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have 
> changed the document type to "Experimental".
> 
> We need to make a decision about the next steps for the document and we see 
> the following options:
> 
> a) Publish it as an experimental RFC
> 
> b) Remove it from the working group and ask an AD to shepherd it
> 
> c) Remove it from the working group and let the authors publish it via the 
> independent submission track.
> 
> In any case it would be nice to let folks play around with it and then, after 
> some time, come back to determine whether there is enough interest to produce 
> a standard.
> 
> Please let us know what you think!
> 
> 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

Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

[Anthony Nadalin]

Is "experimental" the correct classification? Maybe "informational" is more 
appropriate as both of these were discussed. 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, September 10, 2014 4:50 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

Hi all,

in response to the discussions at the last IETF meeting the authors of the 
"Dynamic Client Registration Management Protocol"
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have changed 
the document type to "Experimental".

We need to make a decision about the next steps for the document and we see the 
following options:

a) Publish it as an experimental RFC

b) Remove it from the working group and ask an AD to shepherd it

c) Remove it from the working group and let the authors publish it via the 
independent submission track.

In any case it would be nice to let folks play around with it and then, after 
some time, come back to determine whether there is enough interest to produce a 
standard.

Please let us know what you think!

Ciao
Hannes & Derek



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

Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant"

[Anthony Nadalin]

Not all of us look at individual drafts, and thus I have not previously read 
this, but I did this morning and find that there are issues with the way the 
"code challenge" is specified as this requires pre negation of what/how that 
value was achieved and a large scale deployment that is almost impossible, if a 
JWK were used as the default this could eliminate some of the guess work and 
pre-negotiation work. 

I don't think it's ready for WGLC as there has been no discussion yet.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 27, 2014 8:45 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of 
Possession for the OAuth Authorization Code Grant"

Based on the reaction from a few I thought I should add a few words about this 
working group last call.

There is no requirement to wait a specific timeframe after a document became a 
WG item to issue a working group last call.

In this specific case, the document was around for a while and I didn't see a 
reason for not-finishing it as soon as possible.

Additionally, since the document deals with a security vulnerability that is 
being exploited today I thought it might make sense to get the attention from 
the group to review it.

Finally, it is also a fairly "simple" document (if there is something as simple 
in this working group).

Ciao
Hannes

On 08/26/2014 09:32 PM, Hannes Tschofenig wrote:
> Hi all,
> 
> This is a Last Call for comments on the "Symmetric Proof of Possession 
> for the OAuth Authorization Code Grant" specification.
> 
> The document can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
> 
> Please have your comments in no later than September 9th.
> 
> 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

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

[Anthony Nadalin]

I read the draft and just don’t get it, it overloads some of the basic 
semantics, I’m not quite sure you get the concept of token exchange, has what 
you described been deployed ? or even built ?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, August 11, 2014 7:42 AM
To: Mike Jones
Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token 
Exchange" as an OAuth Working Group Item

I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see 
draft-campbell-oauth-sts as the starting point with Mike and the other 
draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there 
are elements from both that likely need to end up in the final work so a 
consolidation of authors and concepts makes sense.
And yes, there are lots of details that the working group will need to decide 
on going forward that we shouldn't get hung up on right now. Though I believe 
that deciding if the token endpoint is used for general token exchange is an 
important philosophical question that should be answered first. If the token 
endpoint is to be used, I strongly belie that this token exchange should 
leverage and work within the constructs provided and defined by OAuth. That's 
the direction I took with draft-campbell-oauth-sts and yes that involves 
overloading the access_token response parameter with something that's not 
always strictly an access token. The existing token endpoint request/response 
are already rather close to what one might expect in an STS type exchange. I 
find there's a nice elegant simplicity to it but I also see where that 
discomfort might come from. If there's consensus to not use/overload the 
existing stuff, I think it'd be much more appropriate to define a new endpoint. 
A lot of syntactic stuff likely falls out from that decision.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Anthony Nadalin]

John this is for the people that did not hum  at the face to face and not just 
for the people not  at the face to face.

Sent from my Windows Phone

From: John Bradley
Sent: ‎7/‎30/‎2014 7:20 AM
To: Sergey Beryozkin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

No worries.

Some of the people in the F2F piling on with discussion derailed  Hannes 
original question.
>  during the IETF #90 OAuth WG meeting, there was strong
>consensus in
>adopting the "OAuth Token Introspection"
>(draft-richer-oauth-introspection-06.txt) specification as an
>OAuth WG
>work item.
>
>We would now like to verify the outcome of this call for
>adoption on the
>OAuth WG mailing list. Here is the link to the document:
>http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
>
>If you did not hum at the IETF 90 OAuth WG meeting, and have
>an opinion
>as to the suitability of adopting this document as a WG work
>item,
>please send mail to the OAuth WG list indicating your opinion
>(Yes/No).
>
>The confirmation call for adoption will last until August 10,
>2014.  If
>you have issues/edits/comments on the document, please send these
>comments along to the list in your response to this Call for
>Adoption.

People not in the room commenting and asking questions is expected.   People 
who expressed opinions in the room should avoid double counting by making it 
clear they hummed in the room, as our AD may not know everyone's face and name.

I don't know how I became the process monitor.   Normally I am the trouble 
maker.

I believe what passed for consensus in the room was that this ork is in scope 
for the WG and this document can serve as a starting point, but that there are 
things that need to be added.

I think Phil would like a use case document to flesh out peoples understanding. 
 Others who have been working on this longer are hesitant that doing a use case 
document without adopting Justin's document as a starting point, will stall the 
process.

We can however adopt Justin's doc and in parallel add a use case section as 
part of the doc or as a separate doc.

So if you were not in the F2F hum you need to express an opinion on if 
draft-richer-oauth-introspection-06.txt should be adopted by the WG item.

John B.
(PS I was in the room and hummed in favour of adopting this as a work item)

On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin  wrote:

> Hi John
> On 30/07/14 14:59, John Bradley wrote:
>> No,  that those of us who we're fallowing the instructions not to comment if 
>> our hum was recorded in the room, should not hold back given the nature of 
>> the thread has changed.
>>
>> It was also an indication to the char that the original intent of the thread 
>> to judge consensus is impacted by some people who previously hummed piling 
>> on the thread.
>>
> I think I understand, thanks for the clarifications, though it appears to be 
> more subtle to me that various OAuth2 technical ambiguities :-)
>> I am more than fine with discussion.  It probably should have been a 
>> different thread though.
>>
> Thanks, sorry for the noise anyway
>
> Sergey
>> John B.
>> Sent from my iPhone
>>
>>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin  wrote:
>>>
 On 30/07/14 14:42, John Bradley wrote:
 This request for only those not at the F2F to add to the hum has gone a 
 bit off the rails.
>>> Meaning you see too much feedback, is it bad, even if some of it may be off 
>>> topic ?
 For those not in the room there was discussion that the draft needed a 
 method to deal with:
 - Multiple AS
 - Supporting the PoP specs
 - stopping clients or other interceptors of the token from introspecting 
 it.

 Justin stated that his implementation already had a number of those 
 features.

 I offered to help get those into the spec as part of my support for making 
 this a WG item.

 Yes if AS and RS are monolithic and there is only one software vendor, 
 then this is not needed.
>>> Why not ? What is wrong with standardizing an introspection process which 
>>> even RS & AS from the same vendor may want to use as opposed to every 
>>> vendor inventing its own protocol ?
>>>
>>> This is why I thought focusing on the RS to 3rd party only diverts from the 
>>> idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing on 
>>> the RS-to-AS communication, which may not have been considered,
>>>
>>> Cheers, Sergey
>>>

 On the other hand there is evidence that is not the case.

 John B.


 Sent from my iPad

> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin  
> wrote:

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Anthony Nadalin]

I think we need management APIs now to manage the new endpoint, but seriously 
this introspection proposal has privacy issues, to avoid these I would encrypt 
the tokens and then this would be a useless endpoint, also this has issues with 
symmetric POP tokens, but maybe this was only designed to work on bearer tokens.



From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 29, 2014 6:08 PM
To: Phil Hunt; Thomas Broyer
Cc: 
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

So you want a service where the RS can call an HTTP endpoint to see if the 
token is alive or not? That sounds like an awesome idea! Very useful for a 
variety of use cases that people have already mentioned on that list. Maybe 
that service should respond in JSON with, say, { "active": true } if it's still 
valid. That's a great start, and that should obviously be MTI.

But while we're there, we probably want to know what else the token is for, 
since this service will probably know that, so let's add in the "scope" and 
"client_id" and whatever other meta-information we have about the token. If 
this endpoint doesn't have that information? Well then, I guess it can't return 
it. So we need to make sure to be flexible about that while we define a common 
core set of semantics. Flexibility like that is very powerful and could be used 
in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one 
better. I think this is such a fantastic idea that I wrote it all down in RFC 
format:

http://tools.ietf.org/html/draft-richer-oauth-introspection-06

Glad to have you on board, Phil.

 -- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
I think one alternative to an introspection service is a revocation status 
service.

But it is often not needed if token lifetimes are small (minutes / session 
life) compared to the refresh token which might last much longer.

Again having info on the case helps explain the requirements of your case and 
we can tell what the best pattern is.

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer 
mailto:t.bro...@gmail.com>> wrote:

Try it where? When you're the RS trying to determine whether you should accept 
the token or reject it?
Le 30 juil. 2014 02:49, "Mike Jones" 
mailto:michael.jo...@microsoft.com>> a écrit :
Yes, but that’s the simplest thing to determine – try the token and see whether 
it works or not.

From: Thomas Broyer [mailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: mailto:oauth@ietf.org>>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item


Decoding a token with a specific format wouldn't tell you whether the token is 
still live: it could have been revoked before its expiration.
Le 30 juil. 2014 02:16, "Mike Jones" 
mailto:michael.jo...@microsoft.com>> a écrit :
Did you consider standardizing the access token format within that deployment 
so all the parties that needed to could understand it, rather requiring an 
extra round trip to an introspection endpoint so as to be able to understand 
things about it?

I realize that might or might not be practical in some cases, but I haven’t 
heard that alternative discussed, so I thought I’d bring it up.

I also second Phil’s comment that it would be good to understand the use cases 
that this is intended to solve before embarking on a particular solution path.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

We also have a use case where the AS is provided by a partner and the RS is 
provided by AOL. Being able to have a standardized way of validating and 
getting data about the token from the AS would make our implementation much 
simpler as we can use the same mechanism for all Authorization Servers and not 
have to implement one off solutions for each AS.

Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may 
this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not 
there yet on the reasons for an interoperable standard.

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer 
mailto:t.bro...@gmail.com>> wrote:
Yes. This spec is of special interest to the platform we're building for 
http://www.oasis-eu.org/

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig 
mailto:

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

Oh yea, real different, give me a freaking break

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 24, 2014 6:31 PM
To: Anthony Nadalin
Cc: John Bradley; oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

The situations are rather different.

On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) 
but that is OK to do

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM

To: John Bradley
Cc: oauth@ietf.org<mailto:oauth@ietf.org> list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

I'm sorry to miss what will likely be a very engaging meeting today.

The premise that some developers are using OAuth in a insecure way to do 
authentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solution is 
yet another spec which either duplicates some subset of OpenID Connect (in a 
different SDO) or forks how to do SSO/authentication using OAuth.

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I am not against discussion in the WG.

I happen to agree with Phil's fundamental premise that some developers are 
using OAuth in a insecure way to do authentication.

That raises the question of how to best educate them, and or address technical 
barriers.

It is on the second point that people's opinions seem to divide.

Some people thing that if we have a OAuth flow that eliminates the access token 
(primarily to avoid asking for consent as I understand it) and just return a 
id_token from the token endpoint that can be done in a spec short enough to het 
people to read.   The subtext of this is that the Connect specification is too 
large that it scare people,  and they don't find the spec in the first place 
because it is not a RFC.

An other common possession is that if you don't want to prompt the user for 
consent then don't ask for scopes.  Twisting the OAuth spec to not return an 
access token is not OAuth,  yes you could use a different endpoint rather than 
the token endpoint, but that is not OAuth.   Connect was careful not to break 
the OAuth spec.As long as you are willing to take a access token with no 
scopes (the client needs to understand that there are no attributes one way or 
another anyway or it will break) then you don't need to change OAuth.   You can 
publish a profile of connect that satisfies the use case.

I think Mike has largely done that but it might be better being less stingy on 
references back to the larger spec.

The questions are do we modify OAuth to not return an access token, and if so 
how,  and if we do is it still OAuth.

The other largely separable question is do we create confusion in the market 
and slow the the adoption of identity federation on top of OAuth, or find a way 
to make this look like a positive alignment of interests around a subset of 
Connect.

There are a number of options.
1: We can do a profile in the OIDF and publish it as a IETF document.   Perhaps 
the cleanest from an IPR point of view.
2:We can do a profile in the OAuth WG referencing connect.
3:We can do a AD sponsored profile that is not in the OAuth WG.
4:We can do a small spec in OAuth to add response_type to the token endpoint.  
in combination with 1, 2, or 3

I agree that stoping developers doing insecure things needs to be addressed 
somehow.
I am not personally convinced that Oauth without access tokens is sensible.

Looking forward to the meeting:)

John B.

On Jul 24, 2014, at 6:52 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

I'd note that the reaction at the conference to Ian's statement was 
overwhelmingly positive. There was a wide range of industry people here - 
implementers, practitioners, deployers, strategists, etc. - and it seems pretty 
clear that the "rough consensus" of the industry at large is that a4c is not 
wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t 
without its lumps. First, we do see some reinventing the wheel just to reinvent 
the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) 
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley 
mailto:ve7...@ve7jtb.com>>:

I thought I did post this to the list.

I guess I hit the wrong reply on my phone.

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, 
tors...@lodderstedt

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) 
but that is OK to do

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

I'm sorry to miss what will likely be a very engaging meeting today.

The premise that some developers are using OAuth in a insecure way to do 
authentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solution is 
yet another spec which either duplicates some subset of OpenID Connect (in a 
different SDO) or forks how to do SSO/authentication using OAuth.

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I am not against discussion in the WG.

I happen to agree with Phil's fundamental premise that some developers are 
using OAuth in a insecure way to do authentication.

That raises the question of how to best educate them, and or address technical 
barriers.

It is on the second point that people's opinions seem to divide.

Some people thing that if we have a OAuth flow that eliminates the access token 
(primarily to avoid asking for consent as I understand it) and just return a 
id_token from the token endpoint that can be done in a spec short enough to het 
people to read.   The subtext of this is that the Connect specification is too 
large that it scare people,  and they don't find the spec in the first place 
because it is not a RFC.

An other common possession is that if you don't want to prompt the user for 
consent then don't ask for scopes.  Twisting the OAuth spec to not return an 
access token is not OAuth,  yes you could use a different endpoint rather than 
the token endpoint, but that is not OAuth.   Connect was careful not to break 
the OAuth spec.As long as you are willing to take a access token with no 
scopes (the client needs to understand that there are no attributes one way or 
another anyway or it will break) then you don't need to change OAuth.   You can 
publish a profile of connect that satisfies the use case.

I think Mike has largely done that but it might be better being less stingy on 
references back to the larger spec.

The questions are do we modify OAuth to not return an access token, and if so 
how,  and if we do is it still OAuth.

The other largely separable question is do we create confusion in the market 
and slow the the adoption of identity federation on top of OAuth, or find a way 
to make this look like a positive alignment of interests around a subset of 
Connect.

There are a number of options.
1: We can do a profile in the OIDF and publish it as a IETF document.   Perhaps 
the cleanest from an IPR point of view.
2:We can do a profile in the OAuth WG referencing connect.
3:We can do a AD sponsored profile that is not in the OAuth WG.
4:We can do a small spec in OAuth to add response_type to the token endpoint.  
in combination with 1, 2, or 3

I agree that stoping developers doing insecure things needs to be addressed 
somehow.
I am not personally convinced that Oauth without access tokens is sensible.

Looking forward to the meeting:)

John B.

On Jul 24, 2014, at 6:52 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:


I'd note that the reaction at the conference to Ian's statement was 
overwhelmingly positive. There was a wide range of industry people here - 
implementers, practitioners, deployers, strategists, etc. - and it seems pretty 
clear that the "rough consensus" of the industry at large is that a4c is not 
wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t 
without its lumps. First, we do see some reinventing the wheel just to reinvent 
the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) 
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley 
mailto:ve7...@ve7jtb.com>>:

I thought I did post this to the list.

I guess I hit the wrong reply on my phone.

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, 
tors...@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:
Ian Glazer mentioned this in his keynote at CIS yesterday.

His advice was please stop,  we are creating confusion and uncertainty.

We are becoming our own wort enemy. ( my view though Ian may share it)

Returning just an id_ token from the token endpoint has little real value.

Something really useful to do would be sorting out channel_id so we can do PoP 
for id tokens to make them and other cookies 

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

I’m sure it was spun in a way that could be true since there was no technical 
value to Ian’s statement and I’m sure that folks had not read or understand the 
usage.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

I'd note that the reaction at the conference to Ian's statement was 
overwhelmingly positive. There was a wide range of industry people here - 
implementers, practitioners, deployers, strategists, etc. - and it seems pretty 
clear that the "rough consensus" of the industry at large is that a4c is not 
wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t 
without its lumps. First, we do see some reinventing the wheel just to reinvent 
the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) 
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley 
mailto:ve7...@ve7jtb.com>>:

I thought I did post this to the list.

I guess I hit the wrong reply on my phone.

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, 
tors...@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:
Ian Glazer mentioned this in his keynote at CIS yesterday.

His advice was please stop,  we are creating confusion and uncertainty.

We are becoming our own wort enemy. ( my view though Ian may share it)

Returning just an id_ token from the token endpoint has little real value.

Something really useful to do would be sorting out channel_id so we can do PoP 
for id tokens to make them and other cookies secure in the front channel.   I 
think that is a better use of time.

I may be in the minority opinion on that,  it won't be the first time.


John B.
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
You are right from a theoretical perspective. Practically this was caused by 
editorial decisions during the creation of the RFC. As far as I remember, there 
was a definition of the (one) token endpoint response in early versions. No one 
every considered to NOT respond with an access token from the token endpoint. 
So one might call it an implicit assumption.

I'm worried that people get totally confused if an exception is introduced now 
given the broad adoption of OAuth based on this assumption.

regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer 
mailto:t.bro...@gmail.com>>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each 
grant type references Section 5.1, and "access token request" is only defined 
in the context of the defined grant types. Section 2.2 doesn't talk about the 
request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :
Is it? Apart from the implicit grant that does not use token endpoint, all 
other grant references section 5.1 for the response, i.e., all shares the same 
response.

2014-07-23 15:18 GMT-04:00 Thomas Broyer 
mailto:t.bro...@gmail.com>>:

I hadn't realized the JSON response that requires the access_token field is 
defined per grant_type, so I'd be OK to "extend the semantics" as in the 
current draft.
That was actually my main concern: that the token endpoint mandates 
access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :

I agree with John that overloading response_type @ authz endpoint is a bad 
idea. It completely changes the semantics of this parameter. NOTE: what I was 
proposing was not this parameter, but a new parameter response_type @ token 
endpoint.

I also think overloading grant_type is a bad idea since it changes its 
semantics. I quote the definition here again:

grant
credential representing the resource owner's authorization

grant_type
type of grant sent to the token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endpoint, but 
the hint to the token endpoint describing the type of credential the endpoint 
has received. It seems the "control of what is being returned from token 
endpoint"  is just a side effect.

I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in 
as much as "text is the king" for a spec., we probably should not change the 
semantics of it as Torsten points out. If it is ok to change this semantics, I 
believe defining a new parameter to this endpoint to control the response would 
be the best way to go. This is what I have described previously.

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

if we take Ian’s non technical  advice then most of the work in Oauth should be 
put down.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 24, 2014 5:29 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t 
without its lumps. First, we do see some reinventing the wheel just to reinvent 
the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) 
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley 
mailto:ve7...@ve7jtb.com>>:
I thought I did post this to the list.

I guess I hit the wrong reply on my phone.

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, 
tors...@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:
Ian Glazer mentioned this in his keynote at CIS yesterday.

His advice was please stop,  we are creating confusion and uncertainty.

We are becoming our own wort enemy. ( my view though Ian may share it)

Returning just an id_ token from the token endpoint has little real value.

Something really useful to do would be sorting out channel_id so we can do PoP 
for id tokens to make them and other cookies secure in the front channel.   I 
think that is a better use of time.

I may be in the minority opinion on that,  it won't be the first time.


John B.
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
You are right from a theoretical perspective. Practically this was caused by 
editorial decisions during the creation of the RFC. As far as I remember, there 
was a definition of the (one) token endpoint response in early versions. No one 
every considered to NOT respond with an access token from the token endpoint. 
So one might call it an implicit assumption.

I'm worried that people get totally confused if an exception is introduced now 
given the broad adoption of OAuth based on this assumption.

regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer 
mailto:t.bro...@gmail.com>>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each 
grant type references Section 5.1, and "access token request" is only defined 
in the context of the defined grant types. Section 2.2 doesn't talk about the 
request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :
Is it? Apart from the implicit grant that does not use token endpoint, all 
other grant references section 5.1 for the response, i.e., all shares the same 
response.

2014-07-23 15:18 GMT-04:00 Thomas Broyer 
mailto:t.bro...@gmail.com>>:

I hadn't realized the JSON response that requires the access_token field is 
defined per grant_type, so I'd be OK to "extend the semantics" as in the 
current draft.
That was actually my main concern: that the token endpoint mandates 
access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :

I agree with John that overloading response_type @ authz endpoint is a bad 
idea. It completely changes the semantics of this parameter. NOTE: what I was 
proposing was not this parameter, but a new parameter response_type @ token 
endpoint.

I also think overloading grant_type is a bad idea since it changes its 
semantics. I quote the definition here again:

grant
credential representing the resource owner's authorization

grant_type
type of grant sent to the token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endpoint, but 
the hint to the token endpoint describing the type of credential the endpoint 
has received. It seems the "control of what is being returned from token 
endpoint"  is just a side effect.

I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in 
as much as "text is the king" for a spec., we probably should not change the 
semantics of it as Torsten points out. If it is ok to change this semantics, I 
believe defining a new parameter to this endpoint to control the response would 
be the best way to go. This is what I have described previously.

Defining a new endpoint to send code to get ID Token and forbidding the use of 
it against token endpoint would not change the semantics of any existing 
parameter or endpoint, which is good. However, I doubt if it is not worth 
doing. What's the point of avoiding access token scoped to UserInfo endpoint 
after all? Defining a new endpoint for just avoiding the access token for 
userinfo endpoint seems way too much the heavy wait way and it breaks 
interoperabiliy: it defeats t

Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

[Anthony Nadalin]

Is your implementation from the OpenID Connect specification of from the IETF 
specification

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Edmund Jay
Sent: Tuesday, July 15, 2014 11:01 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

I've implemented registration as part of OpenID Connect.

server - https://connect.openid4.us/abop
client - https://connect.openid4.us/abrp



From: Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>
To: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Sent: Tuesday, July 8, 2014 5:46 AM
Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

Hi all,

I am working on the shepherd writeup for the dynamic client registration
draft.

You can find the latest draft here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt

As you can see it is still incomplete.

I would need information about the implementation status.

Ciao
Hannes

___
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] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

ActAs the returned token is expected to be represented by the identity 
described by this parameter
OnBehalfOf the request is being made by the identity described by this parameter

These terms have been pretty clearly defined in the WS specifications, I don't 
understand the confusion. If section 1.3 is confusing, I'm OK with dropping this

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 3, 2014 2:44 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I pointed out a problem with the non normative text in sec 1.3 to Mike off list 
quite a while go.

1.3<http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-1.3>.
  On-Behalf-Of vs. Impersonation Semantics





   When principal A acts on behalf of principal B, A is given all the

   rights that B has within some defined rights context.  Whereas, with

   on-behalf-of semantics, principal A still has its own identity

   separate from B and it is explicitly understood that while B may have

   delegated its rights to A, any actions taken are being taken by A and

   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation

   semantics, with which it is sometimes confused.  When principal A

   impersonates principal B, then in so far as any entity receiving

   Claims is concerned, they are actually dealing with B. It is true

   that some members of the identity system might have awareness that

   impersonation is going on but it is not a requirement.  For all

   intents and purposes, when A is acting for B, A is B.

OnBehalfOf  "indicates that the requestor is making the request on behalf of 
another." and returns a security token to the requestor that contains a single 
set of claims.

ActAs provides a security token/ assertion about subject A in a request from 
Requester B and the response is a composite token that has Requester B as the 
subject but also includes claims about subject A.

See MS FAQ to clarify this  popular question 
http://msdn.microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was trying to get at.

If we can't all agree on the semantics of OnBehalfOf (It has been around for a 
long time) then we have a problem and should pick different terms.

The normative text is correct, however sec 2.2 adds an optional "actor" claim 
to the initial JWT that is to be presented as the value of  on_behalf_of in the 
request.  That is an addition to the WS-Trust text and took me several reads to 
understand that it is not a element in the JWT response.

I offered to help with the spec as I think it is useful.  The semantics are 
tricky for people to understand so I was not all that concerned that the first 
draft was not perfect.

I suspect some concrete examples will help.

John B.

On Jul 3, 2014, at 3:51 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:


I suspect it lines up. But Brian's point may still be relevant. There is *long* 
standing confusion of the terms (because many of have different english 
interpretation than WS-Trust). Might be time for new terms?

Impersonate (or even personate) vs. delegate ?

Those terms differentiate between impersonating a whole person vs. having 
delegate or scoped authority to act for someone.

Sorry if this is an old discussion.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Jul 3, 2014, at 12:20 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:


I'm lost too, as when I wrote this, I explicitly modelled it after WS-Trust.  
If there's a concrete discrepancy you can point out, that would be great.

FYI, I do plan to refresh this draft too allow for a more flexible trust model 
shortly.

        -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I'm lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your d

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

I’m lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be "good enough" 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS 
FAQ<http://msdn.microsoft.com/en-us/library/ee748487.aspx> has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).





On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org<mailto: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] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be "good enough" 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust (this MS 
FAQ has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).






On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
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] Question regarding draft-hunt-oauth-v2-user-a4c

[Anthony Nadalin]

Delegation

From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 5, 2014 12:45 PM
To: Anthony Nadalin
Cc: Bill Mills; Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Examples?

Am 05.06.2014 um 21:42 schrieb Anthony Nadalin 
mailto:tony...@microsoft.com>>:
It’s great but some ways but also very limiting if you are counting on certain 
requirements to be represented in the access token

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1

the access token is opaque to the client. That's great! Let's keep it that way.

Am 05.06.2014 um 21:20 schrieb Bill Mills 
mailto:wmills_92...@yahoo.com>>:
Can't agree more with the peril of overloading auth information into an access 
token.

On Thursday, June 5, 2014 11:05 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Hannes, the Access Token and ID Token do quite different things and have 
different structures and properties.  The Access Token is an opaque value that 
grants access to resources.  An ID Token is a non-opaque JWT security token 
that makes claims about the authentication that occurred.  You can have one 
without the other or you can have both, depending upon the use case.  Thus, 
trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication information 
has been demonstrated in practice to be fraught with peril, and has resulted in 
some of the most prominent security breaches related to the misuse of OAuth.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs happy and 
that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for 
consent to access something. This causes many sites to loose new users. Authen 
only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site 
would like to obtain a higher level of assurance for a higher risk action.

The non-tech requirement is the soln must be received by client and service 
provider developers as easy to implement in addition to 6749 or even OAuth 
1.1a. I mention it because devs feel this should be trivial.  Your suggestion 
of adding to access token certainly fits this.

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig 
> mailto:hannes.tschofe...@gmx.net>> wrote:
>
> Hi Phil,
>
> thanks for producing this document write-up. I have a somewhat basic
> question regarding the document.
>
> The id token contains the following mandatory information:
> - sis: issuer
> - sub: subject
> - aud: audience
> - iat: issued at
> - exp: expiry
> - auth_time: time when the end user was authenticated
>
> An access token (when encoded as a JWT) may contain all these fields
> except the auth_time (since auth_time is not defined in the JWT spec).
>
> Given that your proposal actually does not define the authentication
> protocol to be used between the resource owner/end user and the
> authorisation server I am wondering whether it would be possible to
> just add the auth_time parameter (and maybe some of the optional
> parameters) to the access token. Then, you can skip the id token.
>
> How do I come up with that question? In Kerberos, for example, the
> above-listed information is carried within a single container (within
> the ticket) and so I am curious to hear why we have to send the
> information twice in OAuth (once in the access token, when the info is
> passed per value, and again via the id token).
>
> Maybe I missing something important here.
>
> Ciao
> Hannes
>
>

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


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

___
OAuth mailing list
OAuth@ietf.org<mailto: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] Question regarding draft-hunt-oauth-v2-user-a4c

[Anthony Nadalin]

It’s great but some ways but also very limiting if you are counting on certain 
requirements to be represented in the access token

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1

the access token is opaque to the client. That's great! Let's keep it that way.

Am 05.06.2014 um 21:20 schrieb Bill Mills 
mailto:wmills_92...@yahoo.com>>:
Can't agree more with the peril of overloading auth information into an access 
token.

On Thursday, June 5, 2014 11:05 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Hannes, the Access Token and ID Token do quite different things and have 
different structures and properties.  The Access Token is an opaque value that 
grants access to resources.  An ID Token is a non-opaque JWT security token 
that makes claims about the authentication that occurred.  You can have one 
without the other or you can have both, depending upon the use case.  Thus, 
trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication information 
has been demonstrated in practice to be fraught with peril, and has resulted in 
some of the most prominent security breaches related to the misuse of OAuth.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs happy and 
that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for 
consent to access something. This causes many sites to loose new users. Authen 
only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site 
would like to obtain a higher level of assurance for a higher risk action.

The non-tech requirement is the soln must be received by client and service 
provider developers as easy to implement in addition to 6749 or even OAuth 
1.1a. I mention it because devs feel this should be trivial.  Your suggestion 
of adding to access token certainly fits this.

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig 
> mailto:hannes.tschofe...@gmx.net>> wrote:
>
> Hi Phil,
>
> thanks for producing this document write-up. I have a somewhat basic
> question regarding the document.
>
> The id token contains the following mandatory information:
> - sis: issuer
> - sub: subject
> - aud: audience
> - iat: issued at
> - exp: expiry
> - auth_time: time when the end user was authenticated
>
> An access token (when encoded as a JWT) may contain all these fields
> except the auth_time (since auth_time is not defined in the JWT spec).
>
> Given that your proposal actually does not define the authentication
> protocol to be used between the resource owner/end user and the
> authorisation server I am wondering whether it would be possible to
> just add the auth_time parameter (and maybe some of the optional
> parameters) to the access token. Then, you can skip the id token.
>
> How do I come up with that question? In Kerberos, for example, the
> above-listed information is carried within a single container (within
> the ticket) and so I am curious to hear why we have to send the
> information twice in OAuth (once in the access token, when the info is
> passed per value, and again via the id token).
>
> Maybe I missing something important here.
>
> Ciao
> Hannes
>
>

___
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] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

Where is the confusion ?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

I know a number of people implementing


http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03

Having it on a RFC track may make sense.

I remain to be convinced that a4c ads anything other than confusion.

If the WG wants to take it up it should be aligned with Connect.  I think there 
are more important things to spend time on.


Sent from my iPhone

On May 14, 2014, at 2:24 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.


On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-

Feedback appreciated.

Ciao
Hannes & Derek



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



--
[Ping Identity logo]

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo][youtube 
logo][LinkedIn 
logo][Facebook 
logo][Google+ 
logo][slideshare 
logo][flipboard 
logo][rss feed icon]


[Register for Cloud Identity Summit 2014 | Mod

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

There are folks that are not implementing connect for various reasons (i.e. 
security reasons, complexity reasons, etc.). thus this is compatible with 
connect if folks want to move on to connect,  we surely don’t use connect 
everwhere as it’s over kill where we only need a the functionality of a4c.

From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Wednesday, May 14, 2014 9:39 AM
To: Anthony Nadalin
Cc: Phil Hunt; Brian Campbell; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Can you point to one publicly available or publicly documented implementation 
of a4c?I've never seen one.

I will say the a4c spec is almost 100% overlapped with OpenID Connect.   Some 
minor variations in claim names, but it adds 0 incremental value over what we 
have in Connect.

Connect is being successfully deployed at large scale.  It would be 
irresponsible for this working group to confuse developers and the industry 
with duplicate work, especially given this feels more like an argument over 
signing IPR agreements.

-cmort

On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
I agree with Phil on this one, there are implementations of this already and 
much interest

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

On the contrary. I and others are interested.

We are waiting for the charter to pick up the work.

Regardless there will be a new draft shortly.

Phil

On May 14, 2014, at 5:24, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on 

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

Please list the implementstions

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

I know a number of people implementing


http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03

Having it on a RFC track may make sense.

I remain to be convinced that a4c ads anything other than confusion.

If the WG wants to take it up it should be aligned with Connect.  I think there 
are more important things to spend time on.


Sent from my iPhone

On May 14, 2014, at 2:24 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.


On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-

Feedback appreciated.

Ciao
Hannes & Derek



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



--
[Ping Identity logo]

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo][youtube 
logo][LinkedIn 
logo][Facebook 
logo][Google+ 
logo][slideshare 
logo][flipboard 
logo][rss feed icon]


[Register for Cloud Identity Summit 201

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

I agree with Phil on this one, there are implementations of this already and 
much interest

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

On the contrary. I and others are interested.

We are waiting for the charter to pick up the work.

Regardless there will be a new draft shortly.

Phil

On May 14, 2014, at 5:24, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.


On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-

Feedback appreciated.

Ciao
Hannes & Derek



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



--
[Ping Identity logo]

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo][youtube 
logo][LinkedIn 
logo][Facebook 
logo][Google+ 
logo][slideshare 
logo][flipboard 
logo][rss feed icon]


[Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 
July, 2014 | Monterey, CA]


_

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

[Anthony Nadalin]

I have to agree with Phil on this as there are already spec out there that use 
HoK and PoP , either of these work but prefer HoK as folks get confused with 
PoP as we have seen this within our company already

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, April 3, 2014 11:32 AM
To: John Bradley; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-pop-architecture-00.txt

I agree with what John wrote below.  Besides, PoP is more natural to say than 
HoK and certainly more natural to say than HOTK.  I'd like us to stay with the 
term Proof-of-Possession (PoP).

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, April 03, 2014 11:10 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-pop-architecture-00.txt

Some people and specs associate holder of key with asymmetric keys.  Proof of 
possession is thought to be a broader category including symmetric and key 
agreement eg http://tools.ietf.org/html/rfc2875.

NIST defines the term PoP Protocol 
http://fismapedia.org/index.php?title=Term:Proof_of_Possession_Protocol

In SAML the saml:SubjectConfirmation method  is called 
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key

In WS* the term proof of possession is more common.

So I think for this document as an overview "Proof of Possession (PoP) 
Architecture" is fine.

John B.

On Apr 3, 2014, at 12:41 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

What was wrong with HOK?

Aside: Why was "the" so important in HOTK?

Phil

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

On Apr 3, 2014, at 9:37 AM, Anil Saldhana 
mailto:anil.saldh...@redhat.com>> wrote:

Prateek,
  why not just use "proof"?

draft-hunt-oauth-proof-architecture-00.txt

Is that allowed by IETF?


Regards,
Anil

On 04/03/2014 11:30 AM, Prateek Mishra wrote:
"key confirmed" or "key confirmation" is another term that is widely used for 
these use-cases
I really *like* the name "proof of possession", but I think the acronym PoP is 
going to be confused with POP.  HOTK has the advantage of not being a homonym 
for aything else.  What about "Possession Proof"?

-bill

William J. Mills
"Paranoid" MUX Yahoo!

On Thursday, April 3, 2014 1:38 AM, 
"internet-dra...@ietf.org" 
 wrote:

A new version of I-D, draft-hunt-oauth-pop-architecture-00.txt
has been successfully submitted by Hannes Tschofenig and posted to the
IETF repository.

Name:draft-hunt-oauth-pop-architecture
Revision:00
Title:OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
Document date:2014-04-03
Group:Individual Submission
Pages:21
URL:
http://www.ietf.org/internet-drafts/draft-hunt-oauth-pop-architecture-00.txt
Status:
https://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
Htmlized:  http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-00


Abstract:
  The OAuth 2.0 bearer token specification, as defined in RFC 6750,
  allows any party in possession of a bearer token (a "bearer") to get
  access to the associated resources (without demonstrating possession
  of a cryptographic key).  To prevent misuse, bearer tokens must to be
  protected from disclosure in transit and at rest.

  Some scenarios demand additional security protection whereby a client
  needs to demonstrate possession of cryptographic keying material when
  accessing a protected resource.  This document motivates the
  development of the OAuth 2.0 proof-of-possession security mechanism.




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.

The IETF Secretariat

___
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] Working Group Last Call on Dynamic Client Registration Documents

[Anthony Nadalin]

If these are going to be combined then a draft should be produced and then a 
decision should be made once everyone has a chance to review

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, April 4, 2014 5:49 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

I would combine these two documents, with no normative changes.  This would be 
a convenience for implementers.  And the metadata values that are currently 
optional would remain optional.

I would also add an optional "jwks" metadata member, paralleling this addition 
in OpenID Connect Registration.  This allows the JWK Set to be passed by value, 
rather than by reference.  This was discussed in London and people seemed to 
agree with this change.

The reference to RFC 4627 should be changed to RFC 7159, which has obsoleted 
4627.

Other than that, I believe they're ready to proceed on the next steps towards 
becoming an RFC.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, April 04, 2014 2:14 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we are 
setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

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

Re: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client Registration Specs

[Anthony Nadalin]

Same is true for the registration_client_uri as I may not need/want this, 
should be optional

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, March 6, 2014 7:02 AM
To: Mike Jones; oauth@ietf.org list
Subject: Re: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic 
Client Registration Specs

So the current core makes the registration_access_token  required and there are 
open registration endpoints, so this should be optional, there are also cases 
where the client_id is signed and that becomes the right to the registration 
endpoint

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, February 7, 2014 10:58 AM
To: oauth@ietf.org<mailto:oauth@ietf.org> list
Subject: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client 
Registration Specs

There are now OAuth working group<http://datatracker.ietf.org/wg/oauth/> 
versions of the refactored OAuth Dynamic Client Registration specifications:

* OAuth 2.0 Dynamic Client Registration Core Protocol

* OAuth 2.0 Dynamic Client Registration Metadata

* OAuth 2.0 Dynamic Client Registration Management Protocol

These versions address review comments by Phil Hunt and Tony Nadalin.  Phil is 
now also an author.  The data structures and messages used are the same as the 
previous versions<http://self-issued.info/?p=1171>.

The drafts are available at:

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-00

HTML formatted versions are also available at:

* https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-16.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-metadata-00.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-00.html

-- Mike

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

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

Re: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client Registration Specs

[Anthony Nadalin]

So the current core makes the registration_access_token  required and there are 
open registration endpoints, so this should be optional, there are also cases 
where the client_id is signed and that becomes the right to the registration 
endpoint

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, February 7, 2014 10:58 AM
To: oauth@ietf.org list
Subject: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client 
Registration Specs

There are now OAuth working group 
versions of the refactored OAuth Dynamic Client Registration specifications:

* OAuth 2.0 Dynamic Client Registration Core Protocol

* OAuth 2.0 Dynamic Client Registration Metadata

* OAuth 2.0 Dynamic Client Registration Management Protocol

These versions address review comments by Phil Hunt and Tony Nadalin.  Phil is 
now also an author.  The data structures and messages used are the same as the 
previous versions.

The drafts are available at:

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-00

HTML formatted versions are also available at:

* https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-16.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-metadata-00.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-00.html

-- Mike

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

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

Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

[Anthony Nadalin]

+1  should not be merged

-Original Message-
From: Mike Jones 
Sent: Thursday, March 6, 2014 5:19 AM
To: Anthony Nadalin; tors...@lodderstedt.net; oauth@ietf.org
Subject: RE: [OAUTH-WG] IETF #89 OAuth Meeting Notes

I also disagree with moving "scope" into the core registration spec.  The 
metadata values in the core spec are those that are essential to use to achieve 
registration.  Those in the metadata spec are those that are useful in some 
applications but not needed by some others.  "scope" is of the second class.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, March 06, 2014 1:37 AM
To: tors...@lodderstedt.net; oauth@ietf.org
Subject: Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

I'm not convinced that scope should be in core

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of tors...@lodderstedt.net
Sent: Thursday, March 6, 2014 12:38 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

Hi,

regarding dynamic client registration: it has been suggested to merge core and 
meta data, or at least move some elements (such as scopes) to the core spec. 
Would you please add this?

regards,
Torsten.

Am 05.03.2014 13:43, schrieb Hannes Tschofenig:
> Hi al
> 
> here are the notes from the OAuth f2f meeting this week:
> http://www.ietf.org/proceedings/89/minutes/minutes-89-oauth
> 
> They are rather short! If someone took some more detailed notes please 
> send us a mail.
> 
> 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