Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Tomek, 

> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki :
> 
> Hi Torsten,
> 
> On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt 
>  wrote:
> 
> 
> >> So if I am putting myself in the shoes of somebody who sets out to do that 
> >> - switch an existing SPA client (no backend)
> 
> > I would like to ask you a question: how many SPAs w/o a backend have you 
> > seen in your projects?
> 
> SPA (html+js) utilizing a 3rd party api that requires authorization?
> If you do have a backend, aren't you better of handling the token request on 
> the backend as pointed out here
> https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-component

I agree. 

> My point of putting (no backend) in parenthesis was to not derail this 
> discussion and of course it had the opposite effect.
> 

You know, I you says „don’t look at the green car“ will cause everyone looking 
for it :-) It asked just out of curiosity. 

> >> Is that fair or is that too much of a shortcut? I am familiar with the 
> >> specs you've referenced and have looked at them again, but dealing with a 
> >> SPA, some of the recommendations are not feasible (can't authenticate the 
> >> client, 
> 
> > You could using dynamic registration (see other thread). The protection 
> > would only differ from refresh token rotation if you would use public key 
> > crypto for client authentication.
> 
> Good point. How well is dynamic registration supported across AS? 

I leave that to the vendors :-)

> 
> >> confidentiality in storage? - not sure how to read that in the context of 
> >> a browser)
> 
> > How do you ensure confidentiality of session cookies?
> 
> All I am trying to say is that I think context is important here. So when you 
> point out these best practices, some of them will get people confused as far 
> as what it means in the browser based app scenario.

That’s why we have the more general Security BCP and client-specific BCPs, like 
for native apps (https://tools.ietf.org/html/rfc8252) and the new BCP for SPAs 
Aaron started to work on.

> Maybe it is just me :)

thanks for raising the question! We need this kind of input to govern the 
development of our specs.

kind regards,
Torsten. 

> 
> > 
> > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt 
> >  wrote:
> > 
> > 
> > Hi Tomek,
> > 
> > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 
> > > :
> > > 
> > > I agree with Vittorio, Dominick et al. 
> > > 
> > >> I disagree. 
> > > 
> > >> Existing deployments that have not mitigated against the concerns with 
> > >> implicit should be ripped up and updated.
> > > 
> > > Yes, just like future deployments that will not mitigate against the 
> > > concerns of code in the browser should be a concern.
> > 
> > I agree. That’s why I pointed point yesterday that the Security BCP also 
> > defines obligations for clients using code. 
> > 
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
> > 
> > > 
> > > Can somebody on the other side of the argument (and I hate to make it 
> > > sound like there are two sides, because we're on the same side as far as 
> > > Implicit's AT in front-channel is a real issue) address Dominic's 
> > > comment: 
> > > 
> > >> Also - simply saying “implicit is evil - switch to code” means for most 
> > >> people also using refresh token - so we are treating access tokens in 
> > >> the URL with refresh tokens in session storage (over simplified - but 
> > >> you get the idea).
> > > 
> > > Does the group agree|disagree that a recommendation to switch to code 
> > > should be made as long as it is followed by an explanation and guidance 
> > > on what to do with RTs? The ideas that were floated around 
> > > - Token bound RTs (even though it was pointed out that token binding is 
> > > still considered an emerging standard). So should the recommendation than 
> > > say "switch to code and MUST use token bound RTs"?
> > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or 
> > > switch to code and configure AT to not release RTs for this type of 
> > > client (not sure what that even looks like in a form of a 3rd party 
> > > clients)?
> > > - RTs short lived and bound to a ses

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Tomek, 

> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki :
> 
> Thanks Torsten!
> So if I am putting myself in the shoes of somebody who sets out to do that - 
> switch an existing SPA client (no backend)

I would like to ask you a question: how many SPAs w/o a backend have you seen 
in your projects?

> from Implicit to Code,

> the options to think through can be summed up more or less as following:
> 
> 1. Do not use RTs

That’s what I stated. 

> 2. If you're using RTs, rotate on every refresh AND implement RT token 
> binding (is that stable enough?).

Refresh token rotation and sender constrained refresh tokens are alternative 
methods to replay detection. I think RT rotation is the more actionable 
approach. 

> Also consider binding RT to AS session.

yes.

> 
> Is that fair or is that too much of a shortcut? I am familiar with the specs 
> you've referenced and have looked at them again, but dealing with a SPA, some 
> of the recommendations are not feasible (can't authenticate the client, 

You could using dynamic registration (see other thread). The protection would 
only differ from refresh token rotation if you would use public key crypto for 
client authentication.

> confidentiality in storage? - not sure how to read that in the context of a 
> browser)

How do you ensure confidentiality of session cookies?

kind regards,
Torsten. 

> 
> On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt 
>  wrote:
> 
> 
> Hi Tomek,
> 
> > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 
> > :
> > 
> > I agree with Vittorio, Dominick et al. 
> > 
> >> I disagree. 
> > 
> >> Existing deployments that have not mitigated against the concerns with 
> >> implicit should be ripped up and updated.
> > 
> > Yes, just like future deployments that will not mitigate against the 
> > concerns of code in the browser should be a concern.
> 
> I agree. That’s why I pointed point yesterday that the Security BCP also 
> defines obligations for clients using code. 
> 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
> 
> > 
> > Can somebody on the other side of the argument (and I hate to make it sound 
> > like there are two sides, because we're on the same side as far as 
> > Implicit's AT in front-channel is a real issue) address Dominic's comment: 
> > 
> >> Also - simply saying “implicit is evil - switch to code” means for most 
> >> people also using refresh token - so we are treating access tokens in the 
> >> URL with refresh tokens in session storage (over simplified - but you get 
> >> the idea).
> > 
> > Does the group agree|disagree that a recommendation to switch to code 
> > should be made as long as it is followed by an explanation and guidance on 
> > what to do with RTs? The ideas that were floated around 
> > - Token bound RTs (even though it was pointed out that token binding is 
> > still considered an emerging standard). So should the recommendation than 
> > say "switch to code and MUST use token bound RTs"?
> > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or 
> > switch to code and configure AT to not release RTs for this type of client 
> > (not sure what that even looks like in a form of a 3rd party clients)?
> > - RTs short lived and bound to a session - "Switch to code as long as AT 
> > can bind and revoke RTs when you log out“
> 
> Basically, the AS does not need to issue refresh tokens. If the AS does not 
> issue refresh tokens, the integration pattern for SPAs does not change 
> (beside the code exchange). If the client needs a new access token, it will 
> perform another authorization request.  
> 
> If it does, this adds another layer of security because it allows the client 
> to frequently obtain new access tokens, which can be short-lived and scope 
> restricted. 
> 
> The refresh tokens should be replay protected by issuing new refresh tokens 
> with every refresh and detect replay for refresh tokens belonging to the same 
> grant. 
> 
> The AS may additionally bind refresh tokens to AS sessions, but as it was 
> pointed out by Annabelle and others, there are some implications to be 
> understood and managed in that context.
> 
> You may find more text about refresh tokens in the Security BCP 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12
> 
> kind regards,
> Torsten.
> 
> 
> > 
> > Sorry if I have missed an important detail from the list above, people who 
> > have proposed these id

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Tomek,

> Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 
> :
> 
> I agree with Vittorio, Dominick et al. 
> 
>> I disagree. 
> 
>> Existing deployments that have not mitigated against the concerns with 
>> implicit should be ripped up and updated.
> 
> Yes, just like future deployments that will not mitigate against the concerns 
> of code in the browser should be a concern.

I agree. That’s why I pointed point yesterday that the Security BCP also 
defines obligations for clients using code. 

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1

> 
> Can somebody on the other side of the argument (and I hate to make it sound 
> like there are two sides, because we're on the same side as far as Implicit's 
> AT in front-channel is a real issue) address Dominic's comment: 
> 
>> Also - simply saying “implicit is evil - switch to code” means for most 
>> people also using refresh token - so we are treating access tokens in the 
>> URL with refresh tokens in session storage (over simplified - but you get 
>> the idea).
> 
> Does the group agree|disagree that a recommendation to switch to code should 
> be made as long as it is followed by an explanation and guidance on what to 
> do with RTs? The ideas that were floated around 
> - Token bound RTs (even though it was pointed out that token binding is still 
> considered an emerging standard). So should the recommendation than say 
> "switch to code and MUST use token bound RTs"?
> - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or switch 
> to code and configure AT to not release RTs for this type of client (not sure 
> what that even looks like in a form of a 3rd party clients)?
> - RTs short lived and bound to a session - "Switch to code as long as AT can 
> bind and revoke RTs when you log out“

Basically, the AS does not need to issue refresh tokens. If the AS does not 
issue refresh tokens, the integration pattern for SPAs does not change (beside 
the code exchange). If the client needs a new access token, it will perform 
another authorization request.  

If it does, this adds another layer of security because it allows the client to 
frequently obtain new access tokens, which can be short-lived and scope 
restricted. 

The refresh tokens should be replay protected by issuing new refresh tokens 
with every refresh and detect replay for refresh tokens belonging to the same 
grant. 

The AS may additionally bind refresh tokens to AS sessions, but as it was 
pointed out by Annabelle and others, there are some implications to be 
understood and managed in that context.

You may find more text about refresh tokens in the Security BCP 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12

kind regards,
Torsten. 

> 
> Sorry if I have missed an important detail from the list above, people who 
> have proposed these ideas, feel free to clarify. 

> 
> On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt 
>  wrote: 
> 
> I disagree. 
> 
> Existing deployments that have not mitigated against the concerns with 
> implicit should be ripped up and updated.
> 
> For example, at one time, I think it was Instagram that had deployed implicit 
> because it was easier to do. Once the understood the security implications, 
> they changed the implementation. 
> 
> BCPs are rarely a response to a new threat, their are capturing Best Current 
> Practices so that they become widely deployed.
> 
> 
> 
> 
> On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell 
>  wrote:
>> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying 
>> here. And that was kind of behind the comment I made, or tired to make, 
>> about this in Bangkok, which was (more or less) that I don't think the WG 
>> should be killing implicit outright but rather that it should begin to 
>> recommend against it. 
>> 
>> I'm not exactly sure what that looks like in this document but maybe toning 
>> down some of the scarier language a bit, favoring SHOULDs vs. MUSTs, and 
>> including language that helps a reader understand the recommendations as 
>> being more considerations for new applications/deployments than as a mandate 
>> to rip up existing ones. 
>> 
>> 
>> 
>> On Mon, Dec 3, 2018 at 8:39 AM John Bradley  wrote:
>>> 
>>> We just need to be sensitive to the spin on this.  
>>> 
>> 
>> 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.___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

gt;> Sorry for stepping a bit back from the level of detail the discussion 
>> already reached. I do have some specific comments on the document, but 
>> before bringing those up I wanted to raise a general problem I am 
>> experiencing with this initiative..
>> 
>> I have a number of customers that are reacting to the news with distress. 
>> The language used in some of the communications associated with this 
>> initiative made them feel like some new vulnerability was discovered, 
>> calling for immediate action.
>> The fact is that as far as I can tell, no new, previously unknown fact 
>> informed this decision: no new vulnerability, nor any new technology that 
>> wasn’t available before (the sender constrain is still not actionable for 
>> most customers). The risks of the implicit flow aren’t bigger now than they 
>> were in October.
>> That doesn’t mean that we cannot improve guidance, of course- and now is as 
>> good as any other moment to do so: but at the same time, I think we need to 
>> be cognizant of the *immense* investment in existence today in form of SDKs 
>> and applications built on those SDKs that are predicated on implicit flow, 
>> with our blessing: until very recently the official position was “implicit 
>> is bad but it’s the best we have noawadays”.
>> To me, being cognizant of that means that we should help people to formulate 
>> action proportionate to the risk. And if until yesterday we were ok with 
>> them using implicit, we cannot realistically expect anyone to start changing 
>> all of their apps today, but that’s the message many customers are getting. 
>> TL;DR, I think the community would be well served by clarifying in the 
>> security document that there is no new risk and their existing codebase 
>> didn’t suddenly become less secure and in *urgent* need to update.
>> To attempt a metaphor. We discovered a new drug against headache with milder 
>> side effects than the one we were prescribing them until now, but that 
>> doesn’t mean that they should throw away all the stash they have of the 
>> older drug. The old drug will keep working as it worked until now. Once they 
>> run out of their stash, they should get the new one; or if the old side 
>> effects were particularly bad for them, perhaps they should consider 
>> switching today. But this isn’t a recall. 
>> 
>> And if in fact this group thinks it should be a recall and get everyone off 
>> the old one right now, I think we’ll need to make a much stronger case than 
>> we have done so far.
>> 
>> Thoughts?
>> 
>> Thanks
>> V.
>>  
>> 
>> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt  
>> wrote:
>> Hi Hannes,
>> 
>> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig 
>> > :
>> >
>> > I agree with Aaron here and I think Section 3.8.1.2 of 
>> > draft-ietf-oauth-security-topics-10  already does a pretty good job.
>> 
>> my proposal is to add the following definition (based on 3.8.1.2) to a new 
>> „Terminology" section or to section 2.1.2:
>> 
>> A sender constrained access token scopes the applicability of an access 
>> token to a certain sender.  This sender is
>> obliged to demonstrate knowledge of a certain secret as prerequisite for the 
>> acceptance of that token at the recipient (e.g. a resource server).
>> 
>> >
>> > I was, however, wondering about the subtle implication of the requirement 
>> > for sender constrained tokens. My understanding of the token binding 
>> > discussion, which is one of the ways to provide sender-constrained tokens, 
>> > is that we don’t have good faith in seeing deployment anytime soon. Hence, 
>> > we are essentially (reading in between the lines of Section 3.8.1.2) 
>> > saying that you cannot use implicit grant in a practical setup for the 
>> > web*..
>> 
>> The text shall convey that implicit must not be used at all. The main reason 
>> being it is unprotected against token injection and additionally also cannot 
>> sender constrain tokens.
>> 
>> The second part of the statement relates to other response types and 
>> conditionally opens the MUST NOT in case they are protected against 
>> injection (which is true for the listed response types) and can issue sender 
>> constrained tokens (which does not work today but might work in the future).
>> 
>> kind regards,
>> Torsten.
>> 
>> > 
>> > Am I misunderstanding it?
>> 
>> > 
>> > Ciao
>> > Hannes
>> > 
>> > PS: The

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Interesting. Even on this list people felt to see that moving some logic to a 
backend could solve some of the problems raised. What I want to convey is: the 
solution to a problem in the OAuth space does not necessarily need to be found 
on the OAuth protocol level. That’s a best practice in the same way as some 
OAuth pattern. 

What I’m suggesting is a statement in the BCP like

—
Implementations MAY consider to move authorization code exchange and handling 
of access and refresh tokens to a backend component in order to fulfill their 
security goals. 

Security of the connection between code running in the browser and this backend 
component is assumed to utilize browser-level protection mechanisms. Details 
are out of scope of this document. 
—

> Am 03.12.2018 um 11:19 schrieb John Bradley :
> 
> This is my point.  
> 
> From a security perspective we have a server based confidential client.   The 
> fact that it has a angular or other JS UI protected by a cookie seems to not 
> be especially relucent to OAuth.  
> 
> Perhaps from the developer point of view they have a JS SPA and the only 
> difference to them is in one case they are including the OAuth client and in 
> the other they are using a server based proxy. So they see it as the same.
> 
> Perhaps it is perspective. 
> 
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki  In this type of deployment, as far as OAuth is concerned, isn't the backend 
> web server a confidential client? Is there even anything unique to this 
> situation as far as OAuth security goes? 
> 
> I wouldn't have expected an Angular app that talks to its own server backend 
> that's managing OAuth credentials to fall under the umbrella of this BCP.
> 
> 
> Aaron Parecki
> aaronparecki.com
> 
> 
> 
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt  
> wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend. just 
> a different cut through the web app’s layering 
> 
> All Angular apps I have seen so far work that way. And it makes a lot of 
> sense to me. The backend can aggregate and optimize access to the underlying 
> services without the need to fully expose them.
> 
> Am 02.12.2018 um 00:44 schrieb John Bradley :
> 
>> How is that different from a regular server client with a web interface if 
>> the backed is doing the API calls to the RS?
>> 
>> 
>> 
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an application 
>>> into frontend provided by JS in the browser and a backend, which takes care 
>>> of the business logic and handles tokens and API access. Replay detection 
>>> at the interface between SPA and backend can utilize standard web 
>>> techniques (see OWASP). The backend in turn can use mTLS for sender 
>>> constraining.
>>> 
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>> :
>>> 
>>>> IMHO the best mechanism at hand currently to cope with token 
>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>>>> detection) and issue short living and privilege restricted access tokens.
>>>> 
>>>> Sender constrained access tokens in SPAs need adoption of token binding or 
>>>> alternative mechanism. mtls could potentially work in deployments with 
>>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>>> work. We potentially must consider to warm up application level PoP 
>>>> mechanisms in conjunction with web crypto. Another path to be evaluated 
>>>> could be web auth.
>>>> 
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>>> :
>>>> 
>>>>> I share the concern Brian has, which is also the conclusion I came up 
>>>>> with in my other email sent a few minutes ago.
>>>>> 
>>>>>  
>>>>> 
>>>>> From: OAuth  On Behalf Of Brian Campbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt 
>>>>> Cc: oauth 
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>>  wrote:
>>>>> 
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>>> > 
>>>>> > So you mean at the resource server ensuring the token was really issued 
>>>>> > to the 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

I think the BCP needs to point out there are solutions beyond an app directly 
interacting with AS and RSs from the browser. Otherwise people get the wrong 
impression this is the only way to go. To the contrary and as I pointed out, 
there are a lot of SPAs working as UI of a larger application. 

Any multi user app needs a database. Will this database be directly exposed to 
the frontend? I don’t think so. There will be a backend, exposing relevant 
capabilities to the SPA.

And if this app also uses external services, where do you want to store the 
respective refresh tokens? In the browser’s local storage? I don’t believe so. 
They will go into the same backend & database.

And there are other reasons: No one will ever be able to implement a PSD2 TPP 
as a stand-alone SPA, obviously because it requires a confidential client but 
there are more aspects. 

Moreover, some security objectives can only be achieved if a backend is used.. 
That’s how the discussion started (token binding and the like).

IMHO omitting this option significantly reduces the relevance of the BCP.

I’m not saying we shall describe the interaction between frontend and backend 
in detail. I advocate for pointing out this option and its benefits. That’s it.

> Am 03.12.2018 um 08:30 schrieb Hans Zandbelt :
> 
> 
>> On Mon, Dec 3, 2018 at 4:18 AM David Waite  
>> wrote:
>> If (as Hans proposed) there was a mechanism for javascript to get access 
>> tokens to interact with protected resources in lieu of the client, there 
>> could be BCP around managing that (which would likely also overlap with a 
>> genuine javascript-in-browser client), but unfortunately there aren’t 
>> technical specs to support that sort of architecture yet.
> 
> I agree with Aaron and David that this should be written up elsewhere and 
> hopefully be referred to from this BCP as it is relevant; anyone willing to 
> contribute and/or suggest where "elsewhere" is?
> 
> Hans.
> 
>> 
>> -DW
>> 
>>> On Dec 2, 2018, at 4:43 PM, Aaron Parecki  wrote:
>>> 
>>> In this type of deployment, as far as OAuth is concerned, isn't the backend 
>>> web server a confidential client? Is there even anything unique to this 
>>> situation as far as OAuth security goes? 
>>> 
>>> I wouldn't have expected an Angular app that talks to its own server 
>>> backend that's managing OAuth credentials to fall under the umbrella of 
>>> this BCP.
>>> 
>>> 
>>> Aaron Parecki
>>> aaronparecki.com
>>> 
>>> 
>>> 
>>>> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt 
>>>>  wrote:
>>>> the UI is rendered in the frontend, UI control flow is in the frontend. 
>>>> just a different cut through the web app’s layering 
>>>> 
>>>> All Angular apps I have seen so far work that way. And it makes a lot of 
>>>> sense to me. The backend can aggregate and optimize access to the 
>>>> underlying services without the need to fully expose them.
>>>> 
>>>>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>>>> 
>>>>> How is that different from a regular server client with a web interface 
>>>>> if the backed is doing the API calls to the RS?
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>>>>> I forgot to mention another (architectural) option: split an application 
>>>>>> into frontend provided by JS in the browser and a backend, which takes 
>>>>>> care of the business logic and handles tokens and API access. Replay 
>>>>>> detection at the interface between SPA and backend can utilize standard 
>>>>>> web techniques (see OWASP). The backend in turn can use mTLS for sender 
>>>>>> constraining.
>>>>>> 
>>>>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>>>>> :
>>>>>> 
>>>>>>> IMHO the best mechanism at hand currently to cope with token 
>>>>>>> leakage/replay in SPAs is to use refresh tokens (rotating 
>>>>>>> w/ replay detection) and issue short living and privilege restricted 
>>>>>>> access tokens.
>>>>>>> 
>>>>>>> Sender constrained access tokens in SPAs need adoption of token binding 
>>>>>>> or alternative mechanism. mtls could potentially work in deployments 
>>>>>>> with automated cert rollout but browser UX and in

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

I assume via the session context, carried 
as cookie, token or part of the URL.

> Am 02.12.2018 um 12:54 schrieb Rob Otto :
> 
> Apologies if I'm being dim (it wouldn't be the first time!) but how, in this 
> scenario, do we identify the browser client and authenticate it to the 
> backend, to associate it with the correct token(s)? 
> 
> Cheers (and really interesting discussion so far)
> 
> Rob 
> 
>> On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt  
>> wrote:
>> the UI is rendered in the frontend, UI control flow is in the frontend. just 
>> a different cut through the web app’s layering 
>> 
>> All Angular apps I have seen so far work that way. And it makes a lot of 
>> sense to me. The backend can aggregate and optimize access to the underlying 
>> services without the need to fully expose them.
>> 
>>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>> 
>>> How is that different from a regular server client with a web interface if 
>>> the backed is doing the API calls to the RS?
>>> 
>>> 
>>> 
>>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>>> I forgot to mention another (architectural) option: split an application 
>>>> into frontend provided by JS in the browser and a backend, which takes 
>>>> care of the business logic and handles tokens and API access. Replay 
>>>> detection at the interface between SPA and backend can utilize standard 
>>>> web techniques (see OWASP). The backend in turn can use mTLS for sender 
>>>> constraining.
>>>> 
>>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>>> :
>>>> 
>>>>> IMHO the best mechanism at hand currently to cope with token 
>>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>>>>> detection) and issue short living and privilege restricted access tokens.
>>>>> 
>>>>> Sender constrained access tokens in SPAs need adoption of token binding 
>>>>> or alternative mechanism. mtls could potentially work in deployments with 
>>>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>>>> work. We potentially must consider to warm up application level PoP 
>>>>> mechanisms in conjunction with web crypto. Another     path to be 
>>>>> evaluated could be web auth.
>>>>> 
>>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>>>> :
>>>>> 
>>>>>> I share the concern Brian has, which is also the conclusion I came up 
>>>>>> with in my other email sent a few minutes ago.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> From: OAuth  On Behalf Of Brian Campbell
>>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>>> To: Torsten Lodderstedt 
>>>>>> Cc: oauth 
>>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>>>  wrote:
>>>>>> 
>>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>>>> > 
>>>>>> > So you mean at the resource server ensuring the token was really 
>>>>>> > issued to the client? Isn't that an inherent limitation of all bearer 
>>>>>> > tokens (modulo HTTP token binding, which is still some time off)?
>>>>>> 
>>>>>> Sure. That’s why the Security BCP recommends use of TLS-based methods 
>>>>>> for sender constraining access tokens 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>>>>>  Token Binding for OAuth 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well 
>>>>>> as Mutual TLS for OAuth 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options 
>>>>>> available.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> Unfortunately even when using the token endpoint, for SPA / in-browser 
>>>>>> client applications, the potential mechanisms for 
>>>>>> sender/key-constraining access tokens don't work very well or maybe 
>>>

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

the UI is rendered in the frontend, UI control flow is in the frontend. just a 
different cut through the web app’s layering 

All Angular apps I have seen so far work that way. And it makes a lot of sense 
to me. The backend can aggregate and optimize access to the underlying services 
without the need to fully expose them.

> Am 02.12.2018 um 00:44 schrieb John Bradley :
> 
> How is that different from a regular server client with a web interface if 
> the backed is doing the API calls to the RS?
> 
> 
> 
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>> I forgot to mention another (architectural) option: split an application 
>> into frontend provided by JS in the browser and a backend, which takes care 
>> of the business logic and handles tokens and API access. Replay detection at 
>> the interface between SPA and backend can utilize standard web techniques 
>> (see OWASP). The backend in turn can use mTLS for sender constraining.
>> 
>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt :
>> 
>>> IMHO the best mechanism at hand currently to cope with token leakage/replay 
>>> in SPAs is to use refresh tokens (rotating w/ replay detection) and issue 
>>> short living and privilege restricted access tokens.
>>> 
>>> Sender constrained access tokens in SPAs need adoption of token binding or 
>>> alternative mechanism. mtls could potentially work in deployments with 
>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>> work. We potentially must consider to warm up application level PoP 
>>> mechanisms in conjunction with web crypto. Another path to be evaluated 
>>> could be web auth..
>>> 
>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>> :
>>> 
>>>> I share the concern Brian has, which is also the conclusion I came up with 
>>>> in my other email sent a few minutes ago.
>>>>  
>>>> From: OAuth  On Behalf Of Brian Campbell
>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>> To: Torsten Lodderstedt 
>>>> Cc: oauth 
>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>  
>>>>  
>>>> 
>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>  wrote:
>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>> > 
>>>> > So you mean at the resource server ensuring the token was really issued 
>>>> > to the client? Isn't that an inherent limitation of all bearer tokens 
>>>> > (modulo HTTP token binding, which is still some time off)?
>>>> 
>>>> Sure. That’s why the Security BCP recommends use of TLS-based methods for 
>>>> sender constraining access tokens 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>>>  Token Binding for OAuth 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
>>>> Mutual TLS for OAuth 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options 
>>>> available.
>>>>  
>>>> Unfortunately even when using the token endpoint, for SPA / in-browser 
>>>> client applications, the potential mechanisms for sender/key-constraining 
>>>> access tokens don't work very well or maybe don't work at all. So I don't 
>>>> know that the recommendation is very realistic.
>>>>  
>>>> 
>>>> 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
>> 
>> 
>> ___
>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

I forgot to mention another (architectural) option: split an application into 
frontend provided by JS in the browser and a backend, which takes care of the 
business logic and handles tokens and API access. Replay detection at the 
interface between SPA and backend can utilize standard web techniques (see 
OWASP). The backend in turn can use mTLS for sender constraining.

> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt :
> 
> IMHO the best mechanism at hand currently to cope with token leakage/replay 
> in SPAs is to use refresh tokens (rotating w/ replay detection) and issue 
> short living and privilege restricted access tokens.
> 
> Sender constrained access tokens in SPAs need adoption of token binding or 
> alternative mechanism. mtls could potentially work in deployments with 
> automated cert rollout but browser UX and interplay with fetch needs some 
> work. We potentially must consider to warm up application level PoP 
> mechanisms in conjunction with web crypto. Another path to be evaluated could 
> be web auth.
> 
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig :
>> 
>> I share the concern Brian has, which is also the conclusion I came up with 
>> in my other email sent a few minutes ago.
>>  
>> From: OAuth  On Behalf Of Brian Campbell
>> Sent: Friday, November 30, 2018 11:43 PM
>> To: Torsten Lodderstedt 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>  
>>  
>> 
>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>  wrote:
>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>> > 
>> > So you mean at the resource server ensuring the token was really issued to 
>> > the client? Isn't that an inherent limitation of all bearer tokens (modulo 
>> > HTTP token binding, which is still some time off)?
>> 
>> Sure. That’s why the Security BCP recommends use of TLS-based methods for 
>> sender constraining access tokens 
>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>  Token Binding for OAuth 
>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
>> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) 
>> are the options available.
>>  
>> Unfortunately even when using the token endpoint, for SPA / in-browser 
>> client applications, the potential mechanisms for sender/key-constraining 
>> access tokens don't work very well or maybe don't work at all. So I don't 
>> know that the recommendation is very realistic.
>>  
>> 
>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

IMHO the best mechanism at hand currently to cope with token leakage/replay in 
SPAs is to use refresh tokens (rotating w/ replay detection) and issue short 
living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or 
alternative mechanism. mtls could potentially work in deployments with 
automated cert rollout but browser UX and interplay with fetch needs some work. 
We potentially must consider to warm up application level PoP mechanisms in 
conjunction with web crypto. Another path to be evaluated could be web auth.

> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig :
> 
> I share the concern Brian has, which is also the conclusion I came up with in 
> my other email sent a few minutes ago.
>  
> From: OAuth  On Behalf Of Brian Campbell
> Sent: Friday, November 30, 2018 11:43 PM
> To: Torsten Lodderstedt 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>  
>  
> 
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt  
> wrote:
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> > 
> > So you mean at the resource server ensuring the token was really issued to 
> > the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> > HTTP token binding, which is still some time off)?
> 
> Sure. That’s why the Security BCP recommends use of TLS-based methods for 
> sender constraining access tokens 
> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>  Token Binding for OAuth 
> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) 
> are the options available.
>  
> Unfortunately even when using the token endpoint, for SPA / in-browser client 
> applications, the potential mechanisms for sender/key-constraining access 
> tokens don't work very well or maybe don't work at all. So I don't know that 
> the recommendation is very realistic.
>  
> 
> 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.


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig :
> 
> I agree with Aaron here and I think Section 3.8.1.2 of 
> draft-ietf-oauth-security-topics-10  already does a pretty good job. 

my proposal is to add the following definition (based on 3.8.1.2) to a new 
„Terminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access token 
to a certain sender.  This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for the 
acceptance of that token at the recipient (e.g. a resource server).

> 
> I was, however, wondering about the subtle implication of the requirement for 
> sender constrained tokens. My understanding of the token binding discussion, 
> which is one of the ways to provide sender-constrained tokens, is that we 
> don’t have good faith in seeing deployment anytime soon. Hence, we are 
> essentially (reading in between the lines of Section 3.8.1.2) saying that you 
> cannot use implicit grant in a practical setup for the web*.

The text shall convey that implicit must not be used at all. The main reason 
being it is unprotected against token injection and additionally also cannot 
sender constrain tokens. 

The second part of the statement relates to other response types and 
conditionally opens the MUST NOT in case they are protected against injection 
(which is true for the listed response types) and can issue sender constrained 
tokens (which does not work today but might work in the future). 

kind regards,
Torsten. 

>  
> Am I misunderstanding it?

>  
> Ciao
> Hannes
>  
> PS: The IoT case is likely different. 
>  
> From: OAuth  On Behalf Of Aaron Parecki
> Sent: Saturday, December 1, 2018 3:18 AM
> To: Torsten Lodderstedt 
> Cc: Daniel Fett ; IETF oauth WG 
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>  
> +1
>  
> I would also like to ensure there is a clear definition of "sender 
> constrained" tokens in this BCP.
>  
> Aaron
>  
>  
> On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt 
>  wrote:
> Hi all, 
> 
> based on your feedback on the list and off list, Daniel and I polished the 
> text. That’s our proposal:
> 
> —
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access 
> tokens in the authorization response, such as "token id_token" and "code 
> token id_token“, 
> unless the issued access tokens are sender-constrained and access token 
> injection in 
> the authorization response is prevented. 
> —
> 
> Explantation: 
> - we wanted to have the right balance between a generic definition of the 
> response types we do not recommend/allow to be used and a concrete/actionable 
> list of the affected response types. 
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by 
> William
> 
> We look forward to seeing your feedback.
> 
> kind regards,
> Torsten.  
> 
> > Am 29.11.2018 um 15:15 schrieb John Bradley :
> > 
> > I am ok with that.  
> > 
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt  > wrote:
> > 
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> > > 
> > > That works.
> > 
> > Good!
> > 
> > I just realized this text has an issue with „token“ (only). It would allow 
> > „token“ to be used if the token would sender constrained. This completely 
> > ignores the fact implicit also shall be abandoned because of its 
> > vulnerability for access token injection. 
> > 
> > I therefore propose a modified text: 
> > 
> >In order to avoid these issues, Clients SHOULD NOT use the implicit
> >grant. Furthermore, clients SHOULD only use other response types causing 
> > the authorization server to
> >issue an access token in the authorization response, if the particular 
> > response type detects access token 
> >injection and the issued access tokens are sender-constrained.
> > 
> > Or we just state:
> > 
> >   In order to avoid these issues, Clients SHOULD NOT use the response type 
> > „token". The response types
> > „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued 
> > access tokens are not 
> > sender-constrained.
> > 
> > > 
> > > In fact, I would further go and say MUST NOT but that probably is too 
> > > much for a security consideration.
> > > 
> > 
> > Mike suggested to go with a SHOULD NOT to get the message out but give 
> > implementors time to move/change.
> &g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Brian,

we use „sender constrained tokens“ throughout the BCP to denote tokens bound to 
a sender in possession of a certain key/secret and I thought that was 
established terminology in the group. Are you suggesting „key constrained” 
would be more appropriate?

kind regards,
Torsten.

> Am 30.11.2018 um 21:02 schrieb Brian Campbell :
> 
> As was pointed out to me in WGLC review of the MTLS document, 
> "sender-constrained" has or is likely to be interpreted with a pretty 
> specific meaning of the token being bound to the client and the client 
> authenticating itself to the resource and the resource checking all that 
> matches up. That makes the text more restrictive than is likely intended. 
> Perhaps the text should say something like "sender or key constrained" to 
> allow for different variants of PoP access tokens? 
> 
> 
> 
>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt 
>>  wrote:
>> Hi all, 
>> 
>> based on your feedback on the list and off list, Daniel and I polished the 
>> text. That’s our proposal:
>> 
>> —
>> In order to avoid these issues, clients MUST NOT use the implicit
>> grant (response type "token") or any other response type issuing access 
>> tokens in the authorization response, such as "token id_token" and "code 
>> token id_token“, 
>> unless the issued access tokens are sender-constrained and access token 
>> injection in 
>> the authorization response is prevented. 
>> —
>> 
>> Explantation: 
>> - we wanted to have the right balance between a generic definition of the 
>> response types we do not recommend/allow to be used and a 
>> concrete/actionable list of the affected response types. 
>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported 
>> by William
>> 
>> We look forward to seeing your feedback.
>> 
>> kind regards,
>> Torsten.  
>> 
>> > Am 29.11.2018 um 15:15 schrieb John Bradley :
>> > 
>> > I am ok with that.  
>> > 
>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt > > wrote:
>> > 
>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
>> > > 
>> > > That works.
>> > 
>> > Good!
>> > 
>> > I just realized this text has an issue with „token“ (only). It would allow 
>> > „token“ to be used if the token would sender constrained. This completely 
>> > ignores the fact implicit also shall be abandoned because of its 
>> > vulnerability for access token injection. 
>> > 
>> > I therefore propose a modified text: 
>> > 
>> >In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >grant. Furthermore, clients SHOULD only use other response types 
>> > causing the authorization server to
>> >issue an access token in the authorization response, if the particular 
>> > response type detects access token 
>> >injection and the issued access tokens are sender-constrained.
>> > 
>> > Or we just state:
>> > 
>> >   In order to avoid these issues, Clients SHOULD NOT use the response type 
>> > „token". The response types
>> > „token id_token“ and „code token id_token“ SOULD NOT be used, if the 
>> > issued access tokens are not 
>> > sender-constrained.
>> > 
>> > > 
>> > > In fact, I would further go and say MUST NOT but that probably is too 
>> > > much for a security consideration.
>> > > 
>> > 
>> > Mike suggested to go with a SHOULD NOT to get the message out but give 
>> > implementors time to move/change.
>> > 
>> > > Best,
>> > > 
>> > > Nat
>> > > 
>> > > Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
>> > > 
>> > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
>> > > 
>> > > 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.
>> > >  
>> > > 差出人: Torsten Lodderstedt 
>> > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後
>> > > 宛先: n-sakimura
>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>> > > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
>> > > instead of implicit
>> > 

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi all, 

based on your feedback on the list and off list, Daniel and I polished the 
text. That’s our proposal:

—
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access 
tokens in the authorization response, such as "token id_token" and "code token 
id_token“, 
unless the issued access tokens are sender-constrained and access token 
injection in 
the authorization response is prevented. 
—

Explantation: 
- we wanted to have the right balance between a generic definition of the 
response types we do not recommend/allow to be used and a concrete/actionable 
list of the affected response types. 
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by 
William

We look forward to seeing your feedback.

kind regards,
Torsten.  

> Am 29.11.2018 um 15:15 schrieb John Bradley :
> 
> I am ok with that.  
> 
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt  wrote:
> 
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> > 
> > That works.
> 
> Good!
> 
> I just realized this text has an issue with „token“ (only). It would allow 
> „token“ to be used if the token would sender constrained. This completely 
> ignores the fact implicit also shall be abandoned because of its 
> vulnerability for access token injection. 
> 
> I therefore propose a modified text: 
> 
>In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant. Furthermore, clients SHOULD only use other response types causing 
> the authorization server to
>issue an access token in the authorization response, if the particular 
> response type detects access token 
>injection and the issued access tokens are sender-constrained.
> 
> Or we just state:
> 
>   In order to avoid these issues, Clients SHOULD NOT use the response type 
> „token". The response types
> „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued 
> access tokens are not 
> sender-constrained.
> 
> > 
> > In fact, I would further go and say MUST NOT but that probably is too much 
> > for a security consideration.
> > 
> 
> Mike suggested to go with a SHOULD NOT to get the message out but give 
> implementors time to move/change.
> 
> > Best,
> > 
> > Nat
> > 
> > Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
> > 
> > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
> > 
> > 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.
> >  
> > 差出人: Torsten Lodderstedt 
> > 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> > 宛先: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> > instead of implicit
> >  
> > Hi Nat, 
> > 
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> >> 
> >> I would support
> >> 
> >> 1) clearly defining Implicit as the flow that returns access token from 
> >> the authorization endpoint ( some people confuses implicit as the flow 
> >> that returns ID Token in the front channel)
> > 
> > That’s the current text: 
> > 
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >grant or any other response type causing the authorization server to
> >issue an access token in the authorization response.
> > 
> > What would you like to modify? 
> > 
> >> 
> >> 2) Banning the returning of the access token that are not sender 
> >> constrained from the authorization endpoint
> > 
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >grant or any other response type causing the authorization server to
> >issue an access token in the authorization response, if this access 
> > tokens is not sender-constraint.
> > 
> > What about this?
> > 
> > kind regards,
> > Torsten.
> > 
> >> 
> >> Best,
> >> 
> >> Nat
> >> 
> >> 
> >> Outlook for iOS を入手
> >>  
> >> 差出人: OAuth  (Dick Hardt  の代理)
> >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
> >> 宛先: Hannes Tschofenig
> >> Cc: oauth@ietf.org
> >> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> >> instead of implicit
> >>  
> >> +1
> >> 
> >> While there are various me

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

> Am 28.11.2018 um 23:50 schrieb n-sakimura :
> 
> That works.

Good!

I just realized this text has an issue with „token“ (only). It would allow 
„token“ to be used if the token would sender constrained. This completely 
ignores the fact implicit also shall be abandoned because of its vulnerability 
for access token injection. 

I therefore propose a modified text: 

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant. Furthermore, clients SHOULD only use other response types causing the 
authorization server to
   issue an access token in the authorization response, if the particular 
response type detects access token 
   injection and the issued access tokens are sender-constrained.

Or we just state:

  In order to avoid these issues, Clients SHOULD NOT use the response type 
„token". The response types
„token id_token“ and „code token id_token“ SOULD NOT be used, if the issued 
access tokens are not 
sender-constrained.

> 
> In fact, I would further go and say MUST NOT but that probably is too much 
> for a security consideration.
> 

Mike suggested to go with a SHOULD NOT to get the message out but give 
implementors time to move/change.

> Best,
> 
> Nat
> 
> Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
> 
> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
> 
> 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.
>  
> 差出人: Torsten Lodderstedt 
> 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> 宛先: n-sakimura
> Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>  
> Hi Nat, 
> 
>> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>> 
>> I would support
>> 
>> 1) clearly defining Implicit as the flow that returns access token from the 
>> authorization endpoint ( some people confuses implicit as the flow that 
>> returns ID Token in the front channel)
> 
> That’s the current text: 
> 
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response.
> 
> What would you like to modify? 
> 
>> 
>> 2) Banning the returning of the access token that are not sender constrained 
>> from the authorization endpoint
> 
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response, if this access tokens 
> is not sender-constraint.
> 
> What about this?
> 
> kind regards,
> Torsten.
> 
>> 
>> Best,
>> 
>> Nat
>> 
>> 
>> Outlook for iOS を入手
>>  
>> 差出人: OAuth  (Dick Hardt  の代理)
>> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
>> 宛先: Hannes Tschofenig
>> Cc: oauth@ietf.org
>> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
>> instead of implicit
>>  
>> +1
>> 
>> While there are various mechanisms to alleviate some of the issues of 
>> implicit, I don't think we can recommend specifics, and there may be future 
>> ones in the future. I think we all agree that implicit without any 
>> mitigation is problematic. 
>> 
>> How about we recommend against using implicit alone? 
>> 
>> 
>> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig 
>>  wrote:
>> Hi all,
>> 
>> The authors of the OAuth Security Topics draft came to the conclusion that 
>> it is not possible to adequately secure the implicit flow against token 
>> injection since potential solutions like token binding or JARM are in an 
>> early stage of adoption. For this reason, and since CORS allows 
>> browser-based apps to send requests to the token endpoint, Torsten suggested 
>> to use the authorization code instead of the implicit grant in call cases in 
>> his presentation (see 
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>> 
>> A hum in the room at IETF#103 concluded strong support for his 
>> recommendations. We would like to confirm the discussion on the list.
>> 
>> Please provide a response by December 3rd.
>> 
>> Ciao
>> 
>> Hannes & Rifaat
>> 
>>  
>> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Nat, 

> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> 
> I would support
> 
> 1) clearly defining Implicit as the flow that returns access token from the 
> authorization endpoint ( some people confuses implicit as the flow that 
> returns ID Token in the front channel)

That’s the current text: 

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

What would you like to modify? 

> 
> 2) Banning the returning of the access token that are not sender constrained 
> from the authorization endpoint

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response, if this access tokens 
is not sender-constraint.

What about this?

kind regards,
Torsten.

> 
> Best,
> 
> Nat
> 
> 
> Outlook for iOS を入手
>  
> 差出人: OAuth  (Dick Hardt  の代理)
> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
> 宛先: Hannes Tschofenig
> Cc: oauth@ietf.org
> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>  
> +1
> 
> While there are various mechanisms to alleviate some of the issues of 
> implicit, I don't think we can recommend specifics, and there may be future 
> ones in the future. I think we all agree that implicit without any mitigation 
> is problematic. 
> 
> How about we recommend against using implicit alone? 
> 
> 
> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig  
> wrote:
> Hi all,
> 
> The authors of the OAuth Security Topics draft came to the conclusion that it 
> is not possible to adequately secure the implicit flow against token 
> injection since potential solutions like token binding or JARM are in an 
> early stage of adoption. For this reason, and since CORS allows browser-based 
> apps to send requests to the token endpoint, Torsten suggested to use the 
> authorization code instead of the implicit grant in call cases in his 
> presentation (see 
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
> 
> A hum in the room at IETF#103 concluded strong support for his 
> recommendations. We would like to confirm the discussion on the list.
> 
> Please provide a response by December 3rd.
> 
> 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
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

[Torsten Lodderstedt]

> Am 28.11.2018 um 16:53 schrieb George Fletcher :
> 
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>> Hi George,
>> 
>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>> 
>>> Thanks for the additional section on refresh_tokens. Some additional 
>>> recommendations...
>>> 
>>> 1. By default refresh_tokens are bound to the user's authenticated session. 
>>> When the authenticated session expires or is terminated (whether by the 
>>> user or for some other reason) the refresh_tokenis implicitly revoked.
>> SHOULD or MUST? I would suggest to go with a SHOULD.
> I would say that the AS SHOULD bind the refresh_token to the user's 
> authentication. However, I'd lean more to MUST for session bound 
> refresh_tokens being revoked when the session is terminated.

wfm 

Anyone on the list wanting to object? 

>> 
>>> 2. Clients that need to obtain a refresh_token that exists beyond the 
>>> lifetime of the user's authentication session MUST indicate this need by 
>>> requesting the "offline_access" scope 
>>> (https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). This 
>>> provides for a user consent event making it clear to the user that the 
>>> client is requesting access even when the user's authentication session 
>>> expires. This then becomes the default for mobile apps as the refresh_token 
>>> should not be tied to the web session used to authorize the app.
>> Sounds reasonable, just the scope „offline_access“ is OIDC specific. Is it 
>> time to move it down the stack to OAuth?
> It may be if we want more consistency in the implementation of refresh_token 
> policy across authorization servers.

Who has an opinion on that topic?

>> 
>>> 3. The AS MAY consider putting an upper bound on the lifetime of a 
>>> refresh_token (e.g. 1 year). There is no real need to issue a refresh_token 
>>> that is good indefinitely.
>> I thought I had covered that in the last section. It’s now:
>> 
>> Refresh tokens SHOULD expire if the client has been inactive for some time,
>>  i.e. the refresh token has not been used to obtain fresh access tokens 
>> for
>>  some time. The expiration time is at the discretion of the 
>> authorization server.
>>  It might be a global value or determined based on the client policy or
>>  the grant associated with the refresh token (and its sensitivity).
> This is slightly different but sufficient so +1 for the text :)

Ok, thanks. 

>> 
>> Proposals are welcome!
>> 
>> kind regards,
>> Torsten.
>> 
>> 
>>> This is in addition to the other best practices described.
>>> 
>>> Thanks,
>>> George
>>> 
>>> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>>>> Hi all,
>>>> 
>>>> the new revision contains the following changes:
>>>> 
>>>> * added section on refresh tokens
>>>> * additional justifications for recommendation for code
>>>> * refactored 2.1 in order to distinguish CSRF, authz response replay and 
>>>> mix-up (based on feedback by Joseph Heenan)
>>>> * added requirement to authenticate clients during code exchange (PKCE or 
>>>> client credential) to 2.1.1.
>>>> * changed occurrences of SHALL to MUST
>>>> 
>>>> As always: looking forward for your feedback.
>>>> 
>>>> kind regards,
>>>> Torsten.
>>>> 
>>>> 
>>>>> Am 20.11.2018 um 20:26 schrieb internet-dra...@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 WG of the 
>>>>> IETF.
>>>>> 
>>>>>Title   : OAuth 2.0 Security Best Current Practice
>>>>>Authors : Torsten Lodderstedt
>>>>>  John Bradley
>>>>>  Andrey Labunets
>>>>>  Daniel Fett
>>>>>   Filename: draft-ietf-oauth-security-topics-10.txt
>>>>>   Pages   : 38
>>>>>   Date: 2018-11-20
>>>>> 
>>>>> Abstract:
>>>>>   This document describes best current security practice for OAuth 2.0.
>>>>>   It updates and extends the OAuth 2.0 Security Threat Model to
>&

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

[Torsten Lodderstedt]

Hi George, 

> Am 20.11.2018 um 23:38 schrieb George Fletcher :
> 
> Thanks for the additional section on refresh_tokens. Some additional 
> recommendations...
> 
> 1. By default refresh_tokens are bound to the user's authenticated session. 
> When the authenticated session expires or is terminated (whether by the user 
> or for some other reason) the refresh_tokenis implicitly revoked.

SHOULD or MUST? I would suggest to go with a SHOULD.

> 2. Clients that need to obtain a refresh_token that exists beyond the 
> lifetime of the user's authentication session MUST indicate this need by 
> requesting the "offline_access" scope 
> (https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). This 
> provides for a user consent event making it clear to the user that the client 
> is requesting access even when the user's authentication session expires. 
> This then becomes the default for mobile apps as the refresh_token should not 
> be tied to the web session used to authorize the app.

Sounds reasonable, just the scope „offline_access“ is OIDC specific. Is it time 
to move it down the stack to OAuth?

> 3. The AS MAY consider putting an upper bound on the lifetime of a 
> refresh_token (e.g. 1 year). There is no real need to issue a refresh_token 
> that is good indefinitely. 

I thought I had covered that in the last section. It’s now: 

Refresh tokens SHOULD expire if the client has been inactive for some time, 
i.e. the refresh token has not been used to obtain fresh access tokens 
for 
some time. The expiration time is at the discretion of the 
authorization server. 
It might be a global value or determined based on the client policy or
the grant associated with the refresh token (and its sensitivity).

Proposals are welcome!

kind regards,
Torsten. 


> 
> This is in addition to the other best practices described.
> 
> Thanks,
> George
> 
> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>> Hi all, 
>> 
>> the new revision contains the following changes:
>> 
>> * added section on refresh tokens 
>> * additional justifications for recommendation for code
>> * refactored 2.1 in order to distinguish CSRF, authz response replay and 
>> mix-up (based on feedback by Joseph Heenan)
>> * added requirement to authenticate clients during code exchange (PKCE or 
>> client credential) to 2.1.1.
>> * changed occurrences of SHALL to MUST
>> 
>> As always: looking forward for your feedback.
>> 
>> kind regards,
>> Torsten. 
>> 
>> 
>>> Am 20.11.2018 um 20:26 schrieb internet-dra...@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 WG of the IETF.
>>> 
>>>Title   : OAuth 2.0 Security Best Current Practice
>>>Authors : Torsten Lodderstedt
>>>  John Bradley
>>>  Andrey Labunets
>>>  Daniel Fett
>>> Filename: draft-ietf-oauth-security-topics-10.txt
>>> Pages   : 38
>>> Date: 2018-11-20
>>> 
>>> Abstract:
>>>   This document describes best current security practice for OAuth 2.0.
>>>   It updates and extends the OAuth 2.0 Security Threat Model to
>>>   incorporate practical experiences gathered since OAuth 2.0 was
>>>   published and covers new threats relevant due to the broader
>>>   application of OAuth 2.0.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>> 
>>> 
>>> There are also htmlized versions available at:
>>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>>> 
>>> 
>>> A diff from the previous version is available at:
>>> 
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> 
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> 
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

I still don’t understand why the use case must be solved using a flow issuing 
something in the front channel. 

I would also like to take a closer look. Can you or Nat provide pointers to 
existing implementations? 

> Am 27.11.2018 um 21:36 schrieb John Bradley :
> 
> I understand that, but hat is Nat's concern as I understand it.
> 
> When we say no implicit people, have a problem because implicit is imprecise.
> 
> We are saying no AT returned in the response from the authorization endpoint.
> 
> Nat points out that id_token may contain AT for the self issued client.
> 
> So unless we say that is OK if the AT are sender constrained we wind up 
> implying that a OpenID profile of OAuth is in violation of the BCP.
> 
> I am just trying to make sure everyone is on the same page with why Nat was 
> -1.
> 
> It really has nothing to do with the SPA use case.
> 
> John B.
> 
>> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>> Hi John,
>> 
>> as you said, self issued IDPs 
>> (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are 
>> supposed to provide the response type „id_token“ only. I don’t think the 
>> proposal being discussed here is related to this OIDC mode.
>> 
>> best regards,
>> Torsten.
>> 
>>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>> 
>>> I talked to Nat about this a bit today.
>>> 
>>> The thing he is concerned about is mostly around the self issued IDP that 
>>> doesn't have a token endpoint(atleast not easaly).
>>> 
>>> The main use case for that is the id_token response type where claims are 
>>> retuned in the id_token.
>>> 
>>> Because it is fragment encoded some people call that implicit.   That is 
>>> not what we are trying to stop.
>>> 
>>> In some cases in that flow there may be distributed claims returned with 
>>> access Token inside the id_token.I think most people would agree that 
>>> those should be pop or sender constrained tokens.
>>> 
>>> In the case of self issued the RP would be a server and could do sender 
>>> constrained via some mechinisim that is yet to be defined.
>>> 
>>> So if someone wanted to return a access token in a id_token to do 
>>> distributed claims I don't think we have a problem with that as long as the 
>>> token is protected by being sender constrained in some reasonable way.
>>> 
>>> This is a touch hypothetical from the basic OAuth perspective, so I don't 
>>> know how deep we want to go into it.
>>> 
>>> I think the point is not to accidently prohibit something that could be 
>>> done in future.
>>> 
>>> I also think we should not conflate confidential clients that can 
>>> authenticate to the token endpoint with sender constrained/PoP clients that 
>>> can deal with bound tokens.   Yes both have keys but it is better to 
>>> describe them separately.
>>> 
>>> John B.
>>> 
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab 
>>> >> Hi Nat,
>>> 
>>> I understand you are saying your draft could provide clients with an 
>>> application level mechanism to sender constrain access tokens. That’s great!
>>> 
>>> But I don’t see a binding to response type „token id_token“. Why do you 
>>> want to expose the tokens via the URL to attackers?
>>> 
>>> You could easily use your mechanism with code. That would also give you the 
>>> chance to really authenticate the confidential client before you issue the 
>>> token.
>>> 
>>> kind regards,
>>> Torsten.
>>> 
>>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
>>>> 
>>>> I am not talking about SPA.
>>>> The client is a regular confidential client that is running on a server..
>>>> 
>>>> Best,
>>>> 
>>>> Nat Sakimura
>>>> 
>>>> 
>>>> 2018年11月27日(火) 16:55 Jim Manico :
>>>> Nat,
>>>> 
>>>> How is proof of possession established in a modern web browser in the 
>>>> implicit flow?
>>>> 
>>>> My understanding is that token binding was removed from Chrome recently 
>>>> effectively killing browser-based PoP tokens.
>>>> 
>>>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>>>> 
>>>> Am I missing something?
>>>> 
>>>> Aloha, Jim
>>>> 
&g

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

> Am 27.11.2018 um 21:54 schrieb William Denniss :
> 
> +1 to have language recommending against the use in most cases (without 
> needing to exclude Nat's use-case).

Can you (or someone else) propose text?

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi John, 

as you said, self issued IDPs 
(https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are supposed 
to provide the response type „id_token“ only. I don’t think the proposal being 
discussed here is related to this OIDC mode. 

best regards,
Torsten. 

> Am 27.11.2018 um 20:54 schrieb John Bradley :
> 
> I talked to Nat about this a bit today.  
> 
> The thing he is concerned about is mostly around the self issued IDP that 
> doesn't have a token endpoint(atleast not easaly).  
> 
> The main use case for that is the id_token response type where claims are 
> retuned in the id_token.  
> 
> Because it is fragment encoded some people call that implicit.   That is not 
> what we are trying to stop.   
> 
> In some cases in that flow there may be distributed claims returned with 
> access Token inside the id_token.I think most people would agree that 
> those should be pop or sender constrained tokens.  
> 
> In the case of self issued the RP would be a server and could do sender 
> constrained via some mechinisim that is yet to be defined.  
> 
> So if someone wanted to return a access token in a id_token to do distributed 
> claims I don't think we have a problem with that as long as the token is 
> protected by being sender constrained in some reasonable way.
> 
> This is a touch hypothetical from the basic OAuth perspective, so I don't 
> know how deep we want to go into it.
> 
> I think the point is not to accidently prohibit something that could be done 
> in future.  
> 
> I also think we should not conflate confidential clients that can 
> authenticate to the token endpoint with sender constrained/PoP clients that 
> can deal with bound tokens.   Yes both have keys but it is better to describe 
> them separately.  
> 
> John B. 
> 
> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab 
>  Hi Nat, 
> 
> I understand you are saying your draft could provide clients with an 
> application level mechanism to sender constrain access tokens. That’s great! 
> 
> But I don’t see a binding to response type „token id_token“. Why do you want 
> to expose the tokens via the URL to attackers? 
> 
> You could easily use your mechanism with code. That would also give you the 
> chance to really authenticate the confidential client before you issue the 
> token.
> 
> kind regards,
> Torsten.
> 
> > Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> > 
> > I am not talking about SPA. 
> > The client is a regular confidential client that is running on a server. 
> > 
> > Best, 
> > 
> > Nat Sakimura
> > 
> > 
> > 2018年11月27日(火) 16:55 Jim Manico :
> > Nat,
> > 
> > How is proof of possession established in a modern web browser in the 
> > implicit flow?
> > 
> > My understanding is that token binding was removed from Chrome recently 
> > effectively killing browser-based PoP tokens.
> > 
> > https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> > 
> > Am I missing something?
> > 
> > Aloha, Jim
> > 
> > 
> > 
> > On 11/27/18 9:00 PM, Nat Sakimura wrote:
> >> I am actually -1. 
> >> 
> >> +1 for public client and the tokens that are not sender/key constrained. 
> >> 
> >> Just not being used right now does not mean that it is not useful.. In 
> >> fact, I see it coming. 
> >> Implicit (well, Hybrid “token id_token” really) is very useful in certain 
> >> cases. 
> >> Specifically, when the client is confidential (based on public key pair), 
> >> and uses sender constrained (key-constrained) token such as the one 
> >> explained in 
> >> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is 
> >> very useful. 
> >> (Key-constrained token is the remaining portion of this draft that did not 
> >> get incorporated in the MTLS draft. )
> >> In fact it is the only viable method for Self-Issued OpenID Provider. 
> >> 
> >> So, the text is generally good but it needs to be constrained like “Unless 
> >> the client is confidential and the access token issued is key constrained, 
> >> ... “
> >> 
> >> Best, 
> >> 
> >> Nat Sakimura
> >> 
> >> 
> >> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
> >> +1 to recommend the deprecation of implicit.
> >> 
> >> I don't see a compelling reason to keep implicit when there is an
> >> established alternative that is more secure.
> >> 
> >> Our duty as WG is to give developers the best and most se

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Nat, 

I understand you are saying your draft could provide clients with an 
application level mechanism to sender constrain access tokens. That’s great! 

But I don’t see a binding to response type „token id_token“. Why do you want to 
expose the tokens via the URL to attackers? 

You could easily use your mechanism with code. That would also give you the 
chance to really authenticate the confidential client before you issue the 
token.

kind regards,
Torsten.

> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> 
> I am not talking about SPA. 
> The client is a regular confidential client that is running on a server. 
> 
> Best, 
> 
> Nat Sakimura
> 
> 
> 2018年11月27日(火) 16:55 Jim Manico :
> Nat,
> 
> How is proof of possession established in a modern web browser in the 
> implicit flow?
> 
> My understanding is that token binding was removed from Chrome recently 
> effectively killing browser-based PoP tokens.
> 
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> 
> Am I missing something?
> 
> Aloha, Jim
> 
> 
> 
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>> I am actually -1. 
>> 
>> +1 for public client and the tokens that are not sender/key constrained. 
>> 
>> Just not being used right now does not mean that it is not useful.. In fact, 
>> I see it coming. 
>> Implicit (well, Hybrid “token id_token” really) is very useful in certain 
>> cases. 
>> Specifically, when the client is confidential (based on public key pair), 
>> and uses sender constrained (key-constrained) token such as the one 
>> explained in 
>> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is 
>> very useful. 
>> (Key-constrained token is the remaining portion of this draft that did not 
>> get incorporated in the MTLS draft. )
>> In fact it is the only viable method for Self-Issued OpenID Provider. 
>> 
>> So, the text is generally good but it needs to be constrained like “Unless 
>> the client is confidential and the access token issued is key constrained, 
>> ... “
>> 
>> Best, 
>> 
>> Nat Sakimura
>> 
>> 
>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
>> +1 to recommend the deprecation of implicit.
>> 
>> I don't see a compelling reason to keep implicit when there is an
>> established alternative that is more secure.
>> 
>> Our duty as WG is to give developers the best and most sensible practice.
>> 
>> CORS adoption is currently at 94% according to
>> https://caniuse.com/#feat=cors
>> 
>> Vladimir
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat..sakimura.org/
>> @_nat_en
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> Jim Manico
> Manicode Security
> 
> https://www.manicode.com
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Antonio,

good point. I would assume most SPAs will be public clients. Even if a single 
instance registers dynamically and obtains a secret, this secret can only be 
used as kind of „same originator“ proof (much like PKCE). SPAs with a backend 
can also make the backend a confidential client. There was a thread about SPAs 
& backends on the list recently.

I would argue this is inline with RFC6749 security considerations. Do you see a 
need to add this to the BCP?

kind regards,
Torsten.


> Am 26.11.2018 um 09:18 schrieb Antonio Sanso :
> 
> Hi Torsten,
> 
> nice one. FWIW I am reallly happy to see this happening.
> Quick question though. What is the recommendation about dealing with the 
> client secret in this situation?
> 
> regards
> 
> antonio
> From: OAuth  on behalf of Torsten Lodderstedt 
> 
> Sent: Sunday, November 25, 2018 6:32:53 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>  
> Hi all, 
> 
> I would like to state again what the proposal of the authors of the Security 
> BCP is:
> 
> Here is the respective text from the draft:
> 
> ——
> 
> 2.1.2.  Implicit Grant
> 
>The implicit grant (response type "token") and other response types
>causing the authorization server to issue access tokens in the
>authorization response are vulnerable to access token leakage and
>access token replay as described in Section 3.1, Section 3.2, Section 
> 3..3, and Section 3.6.
> 
>Moreover, no viable mechanism exists to cryptographically bind access
>tokens issued in the authorization response to a certain client as it
>is recommended in Section 2.2.  This makes replay detection for such
>access tokens at resource servers impossible.
> 
>In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response.
> 
>Clients SHOULD instead use the response type "code" (aka
>authorization code grant type) as specified in Section 2.1.1 or any
>other response type that causes the authorization server to issue
>access tokens in the token response.  This allows the authorization
>server to detect replay attempts and generally reduces the attack
>surface since access tokens are not exposed in URLs.  It also allows
>the authorization server to sender-constrain the issued tokens.
> ——
> 
> In my observation, discouraging implicit seems to be the less controversial 
> issue.
> 
> „or any other response type causing the authorization server to issue an 
> access token in the authorization response.“ in the 3rd paragraph caused 
> discussions because it suggests to discourage developers from using ANY 
> response type issuing access tokens in the authorization response. This 
> includes OIDC’s response types „token id_token“, „code token“ & „code token 
> id_token“, where at least  „token id_token“ is used in the wild to implement 
> SPAs.
> 
> Why did we come up with this proposal given at least „token id_token“ & „code 
> token id_token“ protect against injection?
> 
> Two reasons: 
> 
> 1) „token id_token“ does not support sender constrained tokens. Also use of 
> refresh tokens to frequently issue new live-time and privilege restricted 
> access tokens is not supported. „code token id_token“ seems more complex than 
> just „code“+pkce for achieving the same goal.
> 
> 2) Protection against token leakage is rather thin and fragile. There is just 
> a single line of defense (CSP, open redirection prevention, browser history 
> manipulation) implemented by the client. 
> 
> Daniel and I collected some more information and argument at 
> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you 
> might like to give a read.
> 
> My conclusion after 2 weeks of intensive discussions with SPA developers 
> (mostly on twitter): code+pkce is the more secure, simpler, and more 
> versatile approach to (also) implement SPAs. I prefer to approach developers 
> with a clean and robust message instead of a lengthy description of what 
> needs to go right in order to secure a SPA using OAuth. That’s why I think 
> code+pkce should be the recommendation of our working group.
> 
> So please vote in favor of our proposal. I think that’s a huge improvement 
> for OAuth.
> 
> kind regards, 
> Torsten. 
> 
> 
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
> > 
> > I strongly support the recommendation of using code instead of implicit. I 
> > do so based on my own experience in the field [1] and stick to that also 

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

as I said, it’s a recommendation for anyone using the implicit now. If there 
are confidential clients out there using implicit (I don’t think there are), it 
is applicable to them as well. 

> Am 25.11.2018 um 20:55 schrieb Rifaat Shekh-Yusef :
> 
> RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public 
> clients:
> 
> 3.1.2.2.  Registration Requirements
>The authorization server MUST require the following clients to
>register their redirection endpoint:
>o  Public clients.
>o  Confidential clients utilizing the implicit grant type.
> 
> 
> I do not know if anybody is using Implicit with Confidential clients, but 
> just in case, you might want to make it clear that your recommendations are 
> specifically for public clients.
> 
> Regards,
>  Rifaat
> 
> 
> 
> 
>> On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt 
>>  wrote:
>> Hi Rifaat,
>> 
>> this is a recommendation to anyone using implicit now. Implicit can only be 
>> used with public clients, so one could interpret it that way. I could also 
>> envision a SPA to use a backend, which in turn is a confidential client. 
>> There were some posts about this topic on the list recently. 
>> 
>> Does this answer your question?
>> 
>> kind regards,
>> Torsten. 
>> 
>> > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef :
>> > 
>> > Hi Torsten,
>> > 
>> > I am assuming that these recommendations are mainly for Public Clients, 
>> > not Confidential Clients; is that correct?
>> > 
>> > Regards,
>> >  Rifaat
>> > 
>> > 
>> > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt 
>> >  wrote:
>> > Hi all, 
>> > 
>> > I would like to state again what the proposal of the authors of the 
>> > Security BCP is:
>> > 
>> > Here is the respective text from the draft:
>> > 
>> > ——
>> > 
>> > 2.1.2.  Implicit Grant
>> > 
>> >The implicit grant (response type "token") and other response types
>> >causing the authorization server to issue access tokens in the
>> >authorization response are vulnerable to access token leakage and
>> >access token replay as described in Section 3.1, Section 3.2, Section 
>> > 3.3, and Section 3.6.
>> > 
>> >Moreover, no viable mechanism exists to cryptographically bind access
>> >tokens issued in the authorization response to a certain client as it
>> >is recommended in Section 2.2.  This makes replay detection for such
>> >access tokens at resource servers impossible.
>> > 
>> >In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >grant or any other response type causing the authorization server to
>> >issue an access token in the authorization response.
>> > 
>> >Clients SHOULD instead use the response type "code" (aka
>> >authorization code grant type) as specified in Section 2.1.1 or any
>> >other response type that causes the authorization server to issue
>> >access tokens in the token response.  This allows the authorization
>> >server to detect replay attempts and generally reduces the attack
>> >surface since access tokens are not exposed in URLs.  It also allows
>> >the authorization server to sender-constrain the issued tokens.
>> > ——
>> > 
>> > In my observation, discouraging implicit seems to be the less 
>> > controversial issue.
>> > 
>> > „or any other response type causing the authorization server to issue an 
>> > access token in the authorization response.“ in the 3rd paragraph caused 
>> > discussions because it suggests to discourage developers from using ANY 
>> > response type issuing access tokens in the authorization response.. This 
>> > includes OIDC’s response types „token id_token“, „code token“ & „code 
>> > token id_token“, where at least  „token id_token“ is used in the wild to 
>> > implement SPAs.
>> > 
>> > Why did we come up with this proposal given at least „token id_token“ & 
>> > „code token id_token“ protect against injection?
>> > 
>> > Two reasons: 
>> > 
>> > 1) „token id_token“ does not support sender constrained tokens. Also use 
>> > of refresh tokens to frequently issue new live-time and privilege 
>> > restricted access tokens is not supported. „code token id_token“ seems 
>> > more complex tha

Re: [OAUTH-WG] Binding Access Tokens is not enough!

[Torsten Lodderstedt]

Does this mean the RS effectively relies on the user agent to enforce the 
sender constraint (via CORS policy)?

> Am 23.11.2018 um 14:54 schrieb Neil Madden :
> 
> Thanks for doing this Daniel, I think the proposed text is good.
> 
> — Neil
> 
>> On 22 Nov 2018, at 14:42, Daniel Fett  wrote:
>> 
>> Hi all,
>> 
>> I would like to discuss a text proposal for the security BCP.
>> 
>> Background:
>> 
>> Yesterday, Neil pointed out the following problem with binding access tokens 
>> using mTLS or token binding in SPAs:
>> 
>> "I am talking about scripts from places like ad servers that are usually 
>> included via an iframe to enforce the SOP and sandbox them from other 
>> scripts. If they get access to an access token - e.g. via document.referrer 
>> or a redirect or some other leak, then they still act within the same TLS 
>> context as the legitimate client."
>> 
>> The problem is that a browser's TLS stack will attach the proof of 
>> possession no matter which origin started a request.
>> 
>> (This seems like a real downside of token binding - why does it not have the 
>> "same site" option that cookies nowadays have?)
>> 
>> I prepared the following addition to the security BCP and would like to hear 
>> your opinions:
>> 
>> "It is important to note that constraining the sender of a token to a web 
>> browser (using a TLS-based method) does not constrain the origin of the 
>> script that uses the token (lack of origin binding). In other words, if 
>> access tokens are used in a browser (as in a single-page application, SPA) 
>> and the access tokens are sender-constrained using a TLS-based method, it 
>> must be ensured that origins other than the origin of the SPA cannot misuse 
>> the TLS-based sender authentication.
>> 
>> The problem can be illustrated using an SPA on origin A that uses an access 
>> token AT that is bound to the TLS connection between the browser and the 
>> resource server R. If AT leaks to an attacker E, and there is, for example, 
>> an iframe from E's origin loaded in the web browser, that iframe can send a 
>> request to origin R using the access token AT. This request will contain the 
>> proof-of-posession of the (mTLS or token binding) key. The resource server R 
>> therefore cannot distinguish if a request containing a valid access token 
>> originates from origin A or origin E.
>> 
>> If the resource server only accepts the access token in an Authorization 
>> header, then Cross-Origin Resource Sharing (CORS) will protect against this 
>> attack by default. If the resource server accepts the access tokens in other 
>> ways (e.g., as a URL parameter), or if the CORS policy of the resource 
>> server permits requests by origin E, then the TLS-based token binding only 
>> provides protection if the browser is offline."
>> 
>> 
>> The "summary" above this text reads as follows:
>> 
>> "If access tokens are sender-constrained to a web browser, the resource 
>> server MUST ensure that the access token can only be used by the origin to 
>> which the access token was issued (origin binding). One solution for the 
>> resource server to accomplish this is to only accept the access token in an 
>> Authorization header (as described in RFC 6750) and to ensure that the 
>> active CORS policy prevents third parties from sending Authorization 
>> headers. See  for details."
>> 
>> What do you think?
>> 
>> -Daniel
>> 
>> ___
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Rifaat,

this is a recommendation to anyone using implicit now. Implicit can only be 
used with public clients, so one could interpret it that way. I could also 
envision a SPA to use a backend, which in turn is a confidential client. There 
were some posts about this topic on the list recently. 

Does this answer your question?

kind regards,
Torsten. 

> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef :
> 
> Hi Torsten,
> 
> I am assuming that these recommendations are mainly for Public Clients, not 
> Confidential Clients; is that correct?
> 
> Regards,
>  Rifaat
> 
> 
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt 
>  wrote:
> Hi all, 
> 
> I would like to state again what the proposal of the authors of the Security 
> BCP is:
> 
> Here is the respective text from the draft:
> 
> ——
> 
> 2.1.2.  Implicit Grant
> 
>The implicit grant (response type "token") and other response types
>causing the authorization server to issue access tokens in the
>authorization response are vulnerable to access token leakage and
>access token replay as described in Section 3.1, Section 3.2, Section 3.3, 
> and Section 3.6.
> 
>Moreover, no viable mechanism exists to cryptographically bind access
>tokens issued in the authorization response to a certain client as it
>is recommended in Section 2.2.  This makes replay detection for such
>access tokens at resource servers impossible.
> 
>In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response.
> 
>Clients SHOULD instead use the response type "code" (aka
>authorization code grant type) as specified in Section 2.1.1 or any
>other response type that causes the authorization server to issue
>access tokens in the token response.  This allows the authorization
>server to detect replay attempts and generally reduces the attack
>surface since access tokens are not exposed in URLs.  It also allows
>the authorization server to sender-constrain the issued tokens.
> ——
> 
> In my observation, discouraging implicit seems to be the less controversial 
> issue.
> 
> „or any other response type causing the authorization server to issue an 
> access token in the authorization response.“ in the 3rd paragraph caused 
> discussions because it suggests to discourage developers from using ANY 
> response type issuing access tokens in the authorization response. This 
> includes OIDC’s response types „token id_token“, „code token“ & „code token 
> id_token“, where at least  „token id_token“ is used in the wild to implement 
> SPAs.
> 
> Why did we come up with this proposal given at least „token id_token“ & „code 
> token id_token“ protect against injection?
> 
> Two reasons: 
> 
> 1) „token id_token“ does not support sender constrained tokens. Also use of 
> refresh tokens to frequently issue new live-time and privilege restricted 
> access tokens is not supported. „code token id_token“ seems more complex than 
> just „code“+pkce for achieving the same goal.
> 
> 2) Protection against token leakage is rather thin and fragile. There is just 
> a single line of defense (CSP, open redirection prevention, browser history 
> manipulation) implemented by the client. 
> 
> Daniel and I collected some more information and argument at 
> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you 
> might like to give a read.
> 
> My conclusion after 2 weeks of intensive discussions with SPA developers 
> (mostly on twitter): code+pkce is the more secure, simpler, and more 
> versatile approach to (also) implement SPAs. I prefer to approach developers 
> with a clean and robust message instead of a lengthy description of what 
> needs to go right in order to secure a SPA using OAuth. That’s why I think 
> code+pkce should be the recommendation of our working group.
> 
> So please vote in favor of our proposal. I think that’s a huge improvement 
> for OAuth.
> 
> kind regards, 
> Torsten. 
> 
> 
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
> > 
> > I strongly support the recommendation of using code instead of implicit. I 
> > do so based on my own experience in the field [1] and stick to that also 
> > after reading the comments and (what I would call) workarounds on this 
> > thread.
> > 
> > Hans.
> > 
> > [1] 
> > https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
> > 
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt 
> >  wrote:
> > th

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi all, 

I would like to state again what the proposal of the authors of the Security 
BCP is:

Here is the respective text from the draft:

——

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section 3.3, 
and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
——

In my observation, discouraging implicit seems to be the less controversial 
issue.

„or any other response type causing the authorization server to issue an access 
token in the authorization response.“ in the 3rd paragraph caused discussions 
because it suggests to discourage developers from using ANY response type 
issuing access tokens in the authorization response. This includes OIDC’s 
response types „token id_token“, „code token“ & „code token id_token“, where at 
least  „token id_token“ is used in the wild to implement SPAs.

Why did we come up with this proposal given at least „token id_token“ & „code 
token id_token“ protect against injection?

Two reasons: 

1) „token id_token“ does not support sender constrained tokens. Also use of 
refresh tokens to frequently issue new live-time and privilege restricted 
access tokens is not supported. „code token id_token“ seems more complex than 
just „code“+pkce for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is just a 
single line of defense (CSP, open redirection prevention, browser history 
manipulation) implemented by the client. 

Daniel and I collected some more information and argument at 
https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might 
like to give a read.

My conclusion after 2 weeks of intensive discussions with SPA developers 
(mostly on twitter): code+pkce is the more secure, simpler, and more versatile 
approach to (also) implement SPAs. I prefer to approach developers with a clean 
and robust message instead of a lengthy description of what needs to go right 
in order to secure a SPA using OAuth. That’s why I think code+pkce should be 
the recommendation of our working group.

So please vote in favor of our proposal. I think that’s a huge improvement for 
OAuth.

kind regards, 
Torsten. 


> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
> 
> I strongly support the recommendation of using code instead of implicit. I do 
> so based on my own experience in the field [1] and stick to that also after 
> reading the comments and (what I would call) workarounds on this thread.
> 
> Hans.
> 
> [1] 
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
> 
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt  
> wrote:
> that’s certainly true, but that might by a web server with static content 
> only.
> 
> If the server is a real backend, there is even less reasons to use a implicit 
> or hybrid. No even a performance gain in comparison to code.
> 
> Am 21..11.2018 um 14:24 schrieb George Fletcher :
> 
>> An SPA has a backend because it has to be loaded from somewhere :)
>> 
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>>> We had a discussion about this topic on Twitter 
>>> https://twitter.com/Apl3b/status/1064854507606208513
>>> 
>>> 
>>> Outcome is POST requires a backend to receive the request so it’s not a 
>>> viable solution for SPAs.
>>> 
>>> 
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>>>> :
>>>> 
>>>> Post response works OK for server based clients.  I don't think POST works 
>>>> for single page applications.  
>>>> 
>>>> Basically that would be something more like postmessage between two JS 
>>>> apps.  
>>>> 
&g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

that’s certainly true, but that might by a web server with static content only.

If the server is a real backend, there is even less reasons to use a implicit 
or hybrid. No even a performance gain in comparison to code.

> Am 21.11.2018 um 14:24 schrieb George Fletcher :
> 
> An SPA has a backend because it has to be loaded from somewhere :)
> 
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>> We had a discussion about this topic on Twitter 
>> https://twitter.com/Apl3b/status/1064854507606208513
>> 
>> Outcome is POST requires a backend to receive the request so it’s not a 
>> viable solution for SPAs.
>> 
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley :
>>>> 
>>>> Post response works OK for server based clients.  I don't think POST works 
>>>> for single page applications.  
>>>> 
>>>> Basically that would be something more like postmessage between two JS 
>>>> apps.  
>>>> 
>>>> Postmessage also has security issues passing a access token and leaking..  
>>>> 
>>>> Perhaps someone more familiar with SPA can comment on POST.  
>>>> 
>>>> John B. 
>>>> 
>>>> 
>>>> 
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher >>> Hi Mike,
>>>> 
>>>> The Form Post Response Mode keeps the access_token out of the URL, but it 
>>>> doesn't prevent the token from traversing through the browser. So a 
>>>> man-in-the-browser attack may be able to intercept the values. It should 
>>>> help with leakage in logs.
>>>> 
>>>> Thanks,
>>>> George
>>>> 
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>>> Next question – doesn’t using the Form Post Response Mode 
>>>> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html 
>>>> mitigate the threats you’re describing below John?  If so, I believe the 
>>>> Security Topics draft should say this.
>>>> 
>>>>  
>>>> 
>>>> I believe we owe it to readers to present the complete picture, which is 
>>>> why I believe that describing profiles using ID Tokens and the Form Post 
>>>> Response Mode are in scope.
>>>> 
>>>>  
>>>> 
>>>>-- Mike
>>>> 
>>>>  
>>>> 
>>>> From: OAuth  On Behalf Of John Bradley
>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>>> To: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization 
>>>> code instead of implicit
>>>> 
>>>>  
>>>> 
>>>> Yes the at_hash protects the client from accepting an injected AT. 
>>>> 
>>>> Unfortunately it doesn't do anything to protect against leakage in logs or 
>>>> redirects.
>>>> 
>>>> So without the AT using some sort of POP mechanism it is hard to say 
>>>> sending it in a redirect is a good security practice.
>>>> 
>>>> John B.
>>>> 
>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>>> 
>>>> Hi Mike, 
>>>>  
>>>> I agree that OIDC hybrid flows offer additional security over the OAuth 
>>>> implicit grant and are used in the wild. On my slides and in the initial 
>>>> version of the new section, we had included the hybrid OIDC flows because 
>>>> of their known token injection countermeasures.
>>>>  
>>>> I nevertheless feel very uncomfortable to recommend those flows and any 
>>>> flow issuing access tokens in the front channel. In the course of the 
>>>> detailed review of the new text we realized two issues: 
>>>>  
>>>> 1) Since the access token is exposed in the URL, such flows possess a 
>>>> significantly higher risk to leak the access token (e.g. through browser 
>>>> history, open redirection and even referrer headers) than the code grant.
>>>> 2) There is no viable way to sender constrain access tokens issued in the 
>>>> front channel. Given the WG decided to recommend use of sender constraint 
>>>> tokens 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),
>>>>  it seems contradictory to recommend response types not supporting such an 
>>>> approach. 
>>>>  
>>>> kind regards,
>>>> Tors

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

We had a discussion about this topic on Twitter 
https://twitter.com/Apl3b/status/1064854507606208513

Outcome is POST requires a backend to receive the request so it’s not a viable 
solution for SPAs.

> Am 20.11.2018 um 23:29 schrieb John Bradley :
> 
> Post response works OK for server based clients.  I don't think POST works 
> for single page applications.  
> 
> Basically that would be something more like postmessage between two JS apps.  
> 
> Postmessage also has security issues passing a access token and leaking.  
> 
> Perhaps someone more familiar with SPA can comment on POST.  
> 
> John B. 
> 
> 
> 
> On Tue, Nov 20, 2018, 6:40 PM George Fletcher  Hi Mike,
> 
> The Form Post Response Mode keeps the access_token out of the URL, but it 
> doesn't prevent the token from traversing through the browser. So a 
> man-in-the-browser attack may be able to intercept the values. It should help 
> with leakage in logs.
> 
> Thanks,
> George
> 
> On 11/20/18 4:00 PM, Mike Jones wrote:
>> Next question – doesn’t using the Form Post Response Mode 
>> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate 
>> the threats you’re describing below John?  If so, I believe the Security 
>> Topics draft should say this.
>> 
>>  
>> 
>> I believe we owe it to readers to present the complete picture, which is why 
>> I believe that describing profiles using ID Tokens and the Form Post 
>> Response Mode are in scope.
>> 
>>  
>> 
>>-- Mike
>> 
>>  
>> 
>> From: OAuth  On Behalf Of John Bradley
>> Sent: Tuesday, November 20, 2018 7:47 AM
>> To: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization 
>> code instead of implicit
>> 
>>  
>> 
>> Yes the at_hash protects the client from accepting an injected AT. 
>> 
>> Unfortunately it doesn't do anything to protect against leakage in logs or 
>> redirects.
>> 
>> So without the AT using some sort of POP mechanism it is hard to say sending 
>> it in a redirect is a good security practice.
>> 
>> John B.
>> 
>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>> 
>> Hi Mike, 
>>  
>> I agree that OIDC hybrid flows offer additional security over the OAuth 
>> implicit grant and are used in the wild. On my slides and in the initial 
>> version of the new section, we had included the hybrid OIDC flows because of 
>> their known token injection countermeasures.
>>  
>> I nevertheless feel very uncomfortable to recommend those flows and any flow 
>> issuing access tokens in the front channel. In the course of the detailed 
>> review of the new text we realized two issues: 
>>  
>> 1) Since the access token is exposed in the URL, such flows possess a 
>> significantly higher risk to leak the access token (e.g. through browser 
>> history, open redirection and even referrer headers) than the code grant.
>> 2) There is no viable way to sender constrain access tokens issued in the 
>> front channel. Given the WG decided to recommend use of sender constraint 
>> tokens 
>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2),
>>  it seems contradictory to recommend response types not supporting such an 
>> approach. 
>>  
>> kind regards,
>> Torsten. 
>>  
>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
>> :
>>  
>> This description of the situation is an oversimplification..  OpenID Connect 
>> secures the implicit flow against token injection attacks by including the 
>> at_hash (access token hash) in the ID Token, enabling the client to validate 
>> that the access token was created by the issuer in the ID Token (which is 
>> also the OAuth Issuer, as described in RFC 8414).  (Note that this 
>> mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>>  
>> Given the prevalence of this known-good solution for securing the implicit 
>> flow, I would request that the draft be updated to describe this mitigation. 
>>  At the same time, I’m fine with the draft recommending the code flow over 
>> the implicit flow when this mitigation is not used.
>>  
>> Thank you,
>> -- Mike
>>  
>> From: OAuth  On Behalf Of Hannes Tschofenig
>> Sent: Monday, November 19, 2018 2:34 AM
>> To: oauth 
>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend author

Re: [OAUTH-WG] Token Binding & implicit

[Torsten Lodderstedt]

I opt for (4) - Remove support/description of binding of access tokens issued 
from the authorization endpoint 

I think the potential solution we worked out (slide 6) is to complex and the 
security implications of the redirect via the resource servers are still 
unclear.

> Am 18.11.2018 um 13:32 schrieb Brian Campbell 
> :
> 
> During the first OAuth session in Bangkok the question "what to do about 
> token binding & implicit?" was raised. There was some discussion but session 
> time was limited and we had to move on before any real consensus was reached. 
> 
> So I thought I'd bring the question to the WG list to generate some more 
> discussion on the issue. It's also related, at least in part, to a couple of 
> the other ongoing threads on the list about browser based apps and security 
> practices. 
> 
> The slides from the session are linked below. Slides 5 & 6 try and explain 
> the awkwardness of doing Token Binding with implicit. While slide 7 lays out 
> some (not very good) options for how to proceed.
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
> 
> 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.___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

[Torsten Lodderstedt]

Hi all, 

the new revision contains the following changes:

* added section on refresh tokens 
* additional justifications for recommendation for code
* refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up 
(based on feedback by Joseph Heenan)
* added requirement to authenticate clients during code exchange (PKCE or 
client credential) to 2.1.1.
* changed occurrences of SHALL to MUST

As always: looking forward for your feedback.

kind regards,
Torsten. 

> Am 20.11.2018 um 20:26 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>    Authors     : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>  Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-10.txt
>   Pages   : 38
>   Date: 2018-11-20
> 
> Abstract:
>   This document describes best current security practice for OAuth 2.0.
>   It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and covers new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt]

Hi Mike, 

I agree that OIDC hybrid flows offer additional security over the OAuth 
implicit grant and are used in the wild. On my slides and in the initial 
version of the new section, we had included the hybrid OIDC flows because of 
their known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flow 
issuing access tokens in the front channel. In the course of the detailed 
review of the new text we realized two issues: 

1) Since the access token is exposed in the URL, such flows possess a 
significantly higher risk to leak the access token (e.g. through browser 
history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front 
channel. Given the WG decided to recommend use of sender constraint tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), 
it seems contradictory to recommend response types not supporting such an 
approach. 

kind regards,
Torsten. 

> Am 19.11.2018 um 23:13 schrieb Mike Jones 
> :
> 
> This description of the situation is an oversimplification.  OpenID Connect 
> secures the implicit flow against token injection attacks by including the 
> at_hash (access token hash) in the ID Token, enabling the client to validate 
> that the access token was created by the issuer in the ID Token (which is 
> also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation 
> was described in draft-ietf-oauth-mix-up-mitigation.)
>  
> Given the prevalence of this known-good solution for securing the implicit 
> flow, I would request that the draft be updated to describe this mitigation.  
> At the same time, I’m fine with the draft recommending the code flow over the 
> implicit flow when this mitigation is not used.
>  
> Thank you,
> -- Mike
>  
> From: OAuth  On Behalf Of Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth 
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>  
> Hi all,
>  
> The authors of the OAuth Security Topics draft came to the conclusion that it 
> is not possible to adequately secure the implicit flow against token 
> injection since potential solutions like token binding or JARM are in an 
> early stage of adoption. For this reason, and since CORS allows browser-based 
> apps to send requests to the token endpoint, Torsten suggested to use the 
> authorization code instead of the implicit grant in call cases in his 
> presentation 
> (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>  
> A hum in the room at IETF#103 concluded strong support for his 
> recommendations. We would like to confirm the discussion on the list.
>  
> Please provide a response by December 3rd.
>  
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

You mean the binding between refresh tokens and sessions?

> Am 19.11.2018 um 11:03 schrieb Hans Zandbelt :
> 
> +1 to the suggestions that Vladimir raises; I've seen a fair number of 
> requests  in the field for exactly that
> 
> Hans.
> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov 
>>  wrote:
>>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination with 
>>> automatic revocation in case of detected replay attempts. 
>>> 
>>> How does it work? The AS issues a new refresh token with every refresh and 
>>> invalidate the old one. This restricts the lifetime of a refresh token. If 
>>> someone (might be the legit client or an attacker) submits one of the 
>>> older, invalidated refresh token, the AS might interpret this as a signal 
>>> indicating token leakage and revoke the valid refresh token as well. We 
>>> used this technique at Deutsche Telekom since our first OAuth 2.0 
>>> implementation back in 2012.
>> This is a clever solution. Did you experience any false positives, e.g. due 
>> to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the 
>> end-user session at the AS / OP:
>> 
>> A valid refresh causing the session to be refreshed too
>> AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Tomek,

> Am 16.11.2018 um 13:59 schrieb Tomek Stojecki :
> 
> >> The AS can bind the lifetime of the refresh tokens to the session 
> >> lifetime, i.e. automatically revoke it on logout. 
> 
> > Yea, I saw your other email asking about refresh token revocation relating 
> > to session management. Obviously for certain clients, this won't make 
> > sense, but for implicit/browser-based ones it's a nice feature to have.
> 
> I agree that this can be useful, however with where we are today, is this 
> supported by auth servers such that it can distinguish offline from 
> renewable-online clients and only revoke the latter when logging out? 

See other thread on refresh token revocation on logout. There seems to be some 
implementations. Basically, I don’t think the clients needs to now because it 
always needs to be prepared to handle invalid (invalidated) refresh tokens (see 
https://tools.ietf.org/html/rfc6749#section-5.2). 

> 
> > The alternative, as you mentioned, is to not issue refresh tokens and do 
> > token renewal the "same old way" via iframe with prompt=none, while still 
> > using code flow.
> 
> Going from Implicit to Code deals with the problem of sending RT in the URL, 
> which I agree is a plus.

Have you taken a look at 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2? 
It gives all the justification. 

> Is there anything else in a way of an improvement? I still am not comfortable 
> enough with the idea of releasing RTs to the browser clients where it can't 
> be encrypted, prone to xss, etc… 

As already stated. The AS is not required to issue refresh tokens.

If the AS decides to issue refresh tokens, there are ways to protect the 
refresh token from replay even for public clients. 

To start with, the AS may use refresh token rotation in combination with 
automatic revocation in case of detected replay attempts. 

How does it work? The AS issues a new refresh token with every refresh and 
invalidate the old one. This restricts the lifetime of a refresh token. If 
someone (might be the legit client or an attacker) submits one of the older, 
invalidated refresh token, the AS might interpret this as a signal indicating 
token leakage and revoke the valid refresh token as well. We used this 
technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 
2012.

An emerging alternative is to use Token Binding (in browser) or Mutual TLS 
(other clients) to bind the refresh token to the client’s key key pair.

kind regards,
Torsten. 

> 
> 
> -Tomek
> 
> On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen 
>  wrote:
> 
> 
> > It still lacks the ability to issue sender constraint access tokens.
> 
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)? Resource servers don't 
> know the flow the clients might use, especially if/when they have many 
> clients.
> 
> > The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> > i.e. automatically revoke it on logout. 
> 
> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
> 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.
> 
> > The only potential „baby step“ I would see is to move towards „token 
> > id_token“. Since this requires signature/at_hash checks etc. I doubt this 
> > is really easier than moving to code and exchange the code for an access 
> > token. What’s your opinion?
> 
> Even since OIDC arrived, this is the only flow I use for JS/browser-based 
> clients (anything less has always seemed so obviously inferior). So for me 
> and my customers, all browser-based clients I am involved in are already 
> there. Perhaps this is the reason for all of my questions/comments about the 
> recent BCP doc. Given "id_token token", CSP, and using the browser history 
> API to wipe the access token from browser history, we already have a decent 
> set of tools to mitigate attacks. As I already conceded, the only remaining 
> issue (IMO) is the short window of time the access token is in the URL.
> 
> Given that it seems to me that OIDC and OAuth2 are typically used together 
> (at least when a user is involved with authentication), I always wonder why 
> the OAuth and OIDC WGs are separate. Given that so much effort of the two 
> sets of specs overlap, it seems odd to keep adding onto the OAuth specs and 
> ignoring the added features that OIDC provides. I don't mean to derail this 
> thread, or step on any political toes, so apologies in advance.
> 
> 
> -Brock
> 
> ___
> OAuth 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Nat, 

> Am 16.11.2018 um 10:12 schrieb n-sakimura :
> 
> Good points.
> 
>  
> 
> Also, while it may be off-topic, I do see values in implicit flows. In some 
> cases, such as when the AS is inside the firewall or on a localhost (e.g., 
> smartphone), “code flow” is not possible as the client cannot reach the AS 
> directly.

are you saying the browser can send the HTTP GET to the authorization endpoint 
but the JS in the browser cannot send the HTTP POST to the token endpoint? 

> Banning implicit (and thus “token id_token” as well) has this repercussion

First of all we are not banning anything. The OAuth WG does no longer recommend 
to use the implicit for very good reasons, which can be found here 
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi#rfc.section.2.1.2

I would appreciate your comments. 

> and I would not agree to it.

As you were always on the „make it secure“ side, I’m a bit surprised. 

kind regards,
Torsten. 

> 
>  
> 
> Best,
> 
>  
> 
> Nat Sakimura
> 
>  
> 
> From: OAuth  On Behalf Of Brock Allen
> Sent: Friday, November 16, 2018 7:01 AM
> To: Torsten Lodderstedt 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> 
>  
> 
> > It still lacks the ability to issue sender constraint access tokens.
> 
>  
> 
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)? Resource servers don't 
> know the flow the clients might use, especially if/when they have many 
> clients.
> 
>  
> 
> > The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> > i.e. automatically revoke it on logout.
> 
>  
> 
> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
> 
>  
> 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.
> 
>  
> 
> > The only potential „baby step“ I would see is to move towards „token 
> > id_token“. Since this requires signature/at_hash checks etc. I doubt this 
> > is really easier than moving to code and exchange the code for an access 
> > token. What’s your opinion?
> 
>  
> 
> Even since OIDC arrived, this is the only flow I use for JS/browser-based 
> clients (anything less has always seemed so obviously inferior). So for me 
> and my customers, all browser-based clients I am involved in are already 
> there. Perhaps this is the reason for all of my questions/comments about the 
> recent BCP doc. Given "id_token token", CSP, and using the browser history 
> API to wipe the access token from browser history, we already have a decent 
> set of tools to mitigate attacks. As I already conceded, the only remaining 
> issue (IMO) is the short window of time the access token is in the URL.
> 
>  
> 
> Given that it seems to me that OIDC and OAuth2 are typically used together 
> (at least when a user is involved with authentication), I always wonder why 
> the OAuth and OIDC WGs are separate. Given that so much effort of the two 
> sets of specs overlap, it seems odd to keep adding onto the OAuth specs and 
> ignoring the added features that OIDC provides. I don't mean to derail this 
> thread, or step on any political toes, so apologies in advance.
> 
>  
> 
>  
> 
> -Brock
> 
>  
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Brock,

> Am 15.11.2018 um 23:01 schrieb Brock Allen :
> 
> > It still lacks the ability to issue sender constraint access tokens.
> 
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)?

Sure. That’s why the Security BCP recommends use of TLS-based methods for 
sender constraining access tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). 
Token Binding for OAuth 
(https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are 
the options available. 


> Resource servers don't know the flow the clients might use, especially 
> if/when they have many clients.

They don’t need to. All they need to know is how to determine whether the 
sender of the token is the legit client. This is achieved by comparing the hash 
of the token binding id or the cert of the client conveyed in the access token 
with the respective data from the TLS handshake. 

> 
> > The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> > i.e. automatically revoke it on logout. 
> 
> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
> 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.

yes. 

Have you ever experienced issues with the latter approach and the browser’s 3rd 
party cookie policy?

> 
> > The only potential „baby step“ I would see is to move towards „token 
> > id_token“. Since this requires signature/at_hash checks etc. I doubt this 
> > is really easier than moving to code and exchange the code for an access 
> > token. What’s your opinion?
> 
> Even since OIDC arrived, this is the only flow I use for JS/browser-based 
> clients (anything less has always seemed so obviously inferior). So for me 
> and my customers, all browser-based clients I am involved in are already 
> there. Perhaps this is the reason for all of my questions/comments about the 
> recent BCP doc. Given "id_token token", CSP, and using the browser history 
> API to wipe the access token from browser history, we already have a decent 
> set of tools to mitigate attacks. As I already conceded, the only remaining 
> issue (IMO) is the short window of time the access token is in the URL.

There are two angles to approach access token leakage and replay from two 
angles, (a) preventing leakage (that’s what you can do with the browser history 
API, TLS, ...) or (b) detecting replay (that’s what one can do with sender 
constraint access tokens). 

The focus of OAuth/OIDC was on (a) but experiences have shown this is of 
limited effectivity, especially in dynamic/open scenarios, which we are seeing 
increasingly due to open banking, eHealth, eID, …. So sealing the problem from 
both ends seems reasonable.  
 
> 
> Given that it seems to me that OIDC and OAuth2 are typically used together 
> (at least when a user is involved with authentication), I always wonder why 
> the OAuth and OIDC WGs are separate. Given that so much effort of the two 
> sets of specs overlap, it seems odd to keep adding onto the OAuth specs and 
> ignoring the added features that OIDC provides. I don't mean to derail this 
> thread, or step on any political toes, so apologies in advance.

No problem. As already stated, OIDC, esp. FAPI, and OAuth need to be aligned on 
that point. 

Thanks for the insights you shared. We will be publishing another revision of 
the OAuth Security BCP soon, which also adds recommendation and justification 
based on our discussions. 

kind regards, 
Torsten. 

> 
> 
> -Brock
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Brock, 

> Am 15.11.2018 um 15:01 schrieb Brock Allen :
> 
> > Helps to prevent leakage, not injection in the authorization response.
> 
> So then wording and its motivation could get updated to correctly reflect 
> that.
> 
> >> "OAuth 2.0 provides no mechanism for a client to verify that an access 
> >> token was issued to it, which could lead to misuse and possible 
> >> impersonation attacks if a malicious party hands off an access token it 
> >> retrieved through some other means to the client."
> >> 
> >> Sure, but OIDC does provide a mitigation for this (even with implicit).
> >
> >This is about token replay detection at the RS. What mitigation does OIDC 
> >provide here? 
> 
> The wording doesn't go with that, then. My point about OIDC is that with the 
> at_hash in the id_token provides a mitigation so the client can verify that 
> the access token was issued to it.

Understand, you are referring to the token injection prevention provided by 
„token id_token“ or „code token id_token“.. It still lacks the ability to issue 
sender constraint access tokens. So if you wanna take the risk associated with 
bearer tokens you can use it. The Security BCP recommends to use sender 
constraint access tokens, so we cannot recommend response types not supporting 
this pattern. 

> 
> > The implicit grant was not equipped with the ability to issue refresh 
> > tokens simply because the working group didn’t want them to end up in the 
> > browser history, leak through open redirectors etc. This is different with 
> > code since tokens travel directly through a TLS protected connection.
> 
> Well, if limiting the access token renewal to the user's session lifetime 
> wasn't a conscious design goal, it's a very interesting side effect which 
> does limit the potential of an attacker.

That’s true. Note that the effectiveness of limitation depends on the lifetime 
of the issued access tokens. 

The AS can bind the lifetime of the refresh tokens to the session lifetime, 
i.e. automatically revoke it on logout. 

In my opinion, whether this is the most appropriate choice largely depends on 
what the client uses the token for. If the client effectively relies on the AS 
(OP) to login the user and obtain user data that makes sense. If the client has 
an independent login and uses the tokens to access resources (e.g. contacts), 
the session with the AS does not have  a real meaning with respect to this 
client. Potentially the client even stores the refresh token in a backend with 
the user account. 

> 
> > First of all the AS decides whether it issues refresh tokens or not. Having 
> > the ability does not mean the AS must do it. If you feel it’s safer to not 
> > do it. Fine. 
> 
> Sure, and this should be mentioned then somewhere (either in the threats doc 
> or in this proposed best practice doc). Not all end developers using these 
> protocols fully understand the ramifications. 

@Aaron: I suggest this goes to the SPA BCP since this is client specific.

> 
> > It’s still possible to refresh your access tokens the way you mentioned 
> > above by sending another authorization request to the AS. 
> 
> This also could be added as a proposal for an alternative to renewing tokens. 
> It provides more awareness to folks, and aids in a potential best practice 
> depending on the requirements of the consuming app.

I agree. 

> 
> > But let’s assume for a moment the AS, based on its risk assessment, decides 
> > to issue refresh tokens. Can you please explain how an attacker will get 
> > access to this tokens? Especially what the expected strength of the 
> > attacker would need to be?
> 
> I don't have a profile of an attack. But I'm assuming it's no different than 
> anything in the past we've been trying to defend against when we considered 
> the potential for an access token to be exfiltrated. So my point is that an 
> access token will expire so an attacker would then have to go back and 
> re-attack the app to get a new access token to continue to have access to the 
> user's resource. But now with refresh tokens in the picture, the attacker 
> would have both and then not need to go back to the app to continue to have 
> access to the user's resource. 

Largely depends on the refresh token protection. I case of public clients I 
would always recommend to rotation refresh tokens with every refresh. This 
renders the old refresh tokens useless. If the attacker happens to be at the 
lucky end and conducts the first refresh, the AS should be able to detect the 
replay when the legit user tries to refresh. It then shall revoke the active 
(in possession of the attacker) refresh token as well. 

I will add this to the Security BCP.

> 
> > I would also like to understand how a refresh token is any different from a 
> > long living cookie in the browser and what you think is the big difference 
> > to mobile apps when it comes to refresh token handling. 
> 
> To use the cookie, the app must be active, and the 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

[Torsten Lodderstedt]

Hi,

here is the respective text proposal for section 2.1. (Note: we also refactored 
the text in order to disentangle CSRF/replay and mix-up detection).


Clients MUST prevent CSRF and ensure that each authorization response is only 
accepted once. One-time use CSRF tokens carried in the state parameter, which 
are securely bound to the user agent, SHOULD be used for that purpose.

In order to prevent mix-up attacks, clients MUST only process redirect 
responses of the OAuth authorization server they send the respective request to 
and from the same user agent this authorization request was initiated with. 
Clients MUST memorize which authorization server they sent an authorization 
request to and bind this information to the user agent and ensure any 
sub-sequent messages are sent to the same authorization server. Clients SHOULD 
use AS-specific redirect URIs as a means to identify the AS a particular 
response came from.


kind regards,
Torsten. 

> Am 14.11.2018 um 09:26 schrieb Daniel Fett :
> 
> Am 13.11.18 um 17:29 schrieb Brian Campbell:
>> 
>> > Does this "MUST be single-use” not effectively already require the code is 
>> > invalidated after first use? If so why downgrade this to a “SHOULD”?
>> 
>> You are right. My feeling is single use can turn out to be a really hard to 
>> implement requirement. That’s why I would like to relax it. Given we now 
>> have a stronger requirement on client authentication that should be fine. 
>> 
>> Question to the list: what is your implementation experience regarding one 
>> time use authorization codes?
>> 
>> There's a bit of discussion about this on this ticket in the Connect WG: 
>> https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use
>>  FWIW.
>> 
>> I do think that in some systems or architectures it can be difficult to 
>> strictly guarantee that a code can only be used once. And it'd be better for 
>> specs to come to terms with that rather than being unrealistically strict 
>> about it.
>> 
>> We have an AS implementation that does do strict one-time use of the code. 
>> But it comes at a cost including some difficulties with resiliency for any 
>> particular code. Not to mention some troubleshooting and support 
>> issues/questions about it. We haven't gotten to the point of changing 
>> anything but have, from time to time, considered changing the implementation 
>> approach for code to something that would appear to behave the same but 
>> might not 100% guarantee a code could only be used once. 
> From a security point of view: What do we want to achieve?
> 
> I assume that the original text in 6749 tried to ensure that even if an authz 
> code leaks to an attacker, the attacker (or a client on behalf of the 
> attacker) cannot obtain an access token using this code.
> 
> To capture this in a (very strong) security property, we could say: Even if 
> the whole authz response leaks to an attacker, including all browser cookies, 
> the attacker must not be able to obtain a token (or make the client obtain a 
> token) with it (after the legitimate user used the code).
> 
> With the current state of the draft, we can achieve this: We have client 
> authentication and injection prevention (read: PKCE) to prevent any direct 
> use of the code or use of the code in a new session with the client. We 
> further require that each authz response is accepted only once by a client, 
> in particular, we suggest to use a single-use "state" for this purpose.
> 
> TL;DR: With single-use state and client authentication we do not gain 
> security from single-use codes.
> 
> I would be fine with relaxing the requirement on single-use codes in 6749. 
> 
> -Daniel
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Brock,

> Am 09.11.2018 um 21:22 schrieb Brock Allen :
> 
> Hello all --
> 
> I also have some thoughts/feedback on this document.
> 
> Personally I agree with some of the conclusions, but as it stands I think the 
> document's main conclusion that code flow is the real solution is not 
> sufficiently convincing.
> 
> I would like to see a brief summary of the current concerns (much like 
> RFC8252 does) so we have context before the document just jumps to what a 
> best practice is. The reason I bring this up is that generally the concept of 
> "best practice" is meaningless without context. I think stating that code 
> flow is best practice without motivation seems somewhat "cart before the 
> horse".
> 
> I think just a short blurb about the desire to eliminate the access token 
> from being delivered in the URL, and the current attacks against doing so 
> would be helpful (showing attacks is super important in making this "real"). 
> I guess this would make the most sense in section "4. Overview" prior to the 
> list of "best practice" conclusions.
> 

I agree, justifications are needed. As draft-ietf-oauth-security-topics-09 
provides those justifications, I suggest to add suitable references here. 

> Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into 
> specifics, but many of the points seem confused (or at least confuse me) 
> and/or the conclusion that code flow is the only approach seems misleading. 
> For example:
> 
> "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required 
> according to Section 6), so clients and authorization servers MUST NOT use 
> the Implicit Flow for browser-based apps.“

Don’t understand the wording either. The text should state that the implicit 
cannot detect token injection.

> 
> This is specious. The threat is the token is in the URL, not that implicit 
> clients can't use PKCE. So perhaps the document should explain the variety of 
> mitigations, not just one? While code flow is one, using CSP and the browser 
> history API to remove the token from the URL is another.

Helps to prevent leakage, not injection in the authorization response. 

> Elsewhere in the document the use of CSP is a "SHOULD". That's great, but 
> using CSP can be and is used today, and doesn't necessitate code flow.
> 
> "OAuth 2.0 provides no mechanism for a client to verify that an access token 
> was issued to it, which could lead to misuse and possible impersonation 
> attacks if a malicious party hands off an access token it retrieved through 
> some other means to the client."
> 
> Sure, but OIDC does provide a mitigation for this (even with implicit).

This is about token replay detection at the RS. What mitigation does OIDC 
provide here? 

> So perhaps it should be offered as a suggestion as well? I did see the point 
> that with code flow id_token validation could instead rely upon the token 
> endpoint, but the client still has other work to do (namely around PKCE). 
> That's just trading one bit of work for another, not a clear cut reason to 
> use one flow over another.
> 
> "Supporting the implicit flow requires additional code, more upkeep and 
> understanding of the related security considerations, while limiting the 
> authorization server to just the authorization code flow simplifies the 
> implementation."
> 
> As offered by someone else already, this is opinion and not objective. IMO, 
> this diminishes the potential of this document.
> 
> "If the JavaScript application gets wrapped into a native app, then [RFC8252] 
> also requires the use of the authorization code flow."
> 
> Given how many browser dependencies SPA apps tend to have, is this really 
> common? In all my years building both, I've never seen it.
> 
> "Historically, the Implicit flow provided an advantage to single-page apps 
> since JavaScript could always arbitrarily read and manipulate the fragment 
> portion of the URL without triggering a page reload. Now with the Session 
> History API (described in "Session history and navigation" of [HTML]), 
> browsers have a mechanism to modify the path component of the URL without 
> triggering a page reload, so this overloaded use of the fragment portion is 
> no longer needed."
> 
> While this section is intended to indicate the existence of the history API 
> is a reason to move away from implicit, it's also what can be used to protect 
> token exposure in the URL, which I think weakens its point. As a section, to 
> me, it seems unnecessary.
> 
> The push to a single flow (for consistency) is a marginal motivation, and I 
> agree with that theme in the document.
> 
> Much of the other guidance in this document is already covered elsewhere 
> (e.g. RFC6819). I don't know if the goal of the document is to reproduce 
> those existing recommendations (as a contrast RFC8252 does not and mainly 
> focuses on what's unique to the native scenario).
> 
> I can't quite tell the real motivation for this "best practice" 

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

[Torsten Lodderstedt]

Hi Evan, 

I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just 
plain X.509). What’s your plan for introducing OAuth and mtls?

kind regards,
Torsten. 

> Am 13.11.2018 um 00:59 schrieb Evan Gilman :
> 
> Thank you everyone for the feedback.
> 
> I am currently working on the sample text, and should be complete in
> the next couple days. Apologies for the delay.
> On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell
>  wrote:
>> 
>> Sure, I think they could be treated as different different 
>> client_auth_methods. But there is a lot more commonality than differences to 
>> the point where I think it makes sense to keep it all in a single document 
>> and under a single client auth method with just the variation on which name 
>> is being used.
>> 
>> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer  wrote:
>>> 
>>> Would it make sense for these to be a different client_auth_method 
>>> entirely? Much the same way that we have private_key_jwt and 
>>> client_secret_jwt today, both of which use the JWT assertion framework but 
>>> have very different keying and security assumptions. In the same way, here 
>>> you’re still validating the cert but the means by which it’s validated is 
>>> different, so the auth method is arguably not going to benefit from being 
>>> overloaded. Caveat, I’ve not built out a system using SANs in any 
>>> meaningful way.
>>> 
>>> If we were to do that, this draft could go forward as-is (since it’s fairly 
>>> done in my opinion) and a new document could better define the semantics 
>>> for the various SAN types, but while building on the framework and concepts 
>>> listed in here.
>>> 
>>> — Justin
>>> 
>>> On Nov 6, 2018, at 3:52 PM, Evan Gilman  wrote:
>>> 
>>> Response(s) inline
>>> 
>>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden  
>>> wrote:
>>> 
>>> 
>>> Is there an intention that any semantics are attached to the SAN being a 
>>> URI or DNS name or IP or ...? Or is it still intended to be an opaque 
>>> identifier?
>>> 
>>> 
>>> There are some extra things we could do if we attached type-specific
>>> semantics to the matching (e.g. DNS wildcarding etc), however I think
>>> that continuing to use the values as opaque identifiers would get us
>>> most of what we need while keeping things simple.
>>> 
>>> On 6 Nov 2018, at 01:55, Brian Campbell 
>>>  wrote:
>>> 
>>> Thanks Evan for bringing this to the WG's attention. More or less the same 
>>> question/issue was raised yesterday in the area director's review of the 
>>> document as well. I plan to bring this up as a discussion item in the 
>>> meeting today. But my sense from some early discussions is that there is 
>>> likely to be (rough) consensus to make some change in order to allow a SAN 
>>> to be specified as the certificate subject identifier in the PKI client 
>>> auth mode. We'll need to figure out the specifics of how that works. I 
>>> don't think there are significant drawbacks to extending the number of 
>>> client registration metadata parameters per se. I guess I've just been 
>>> attracted to the idea of overloading the existing value because that felt 
>>> like maybe a less invasive change. But perhaps that's shortsighted. And 
>>> there's nothing inherently wrong with additional client metadata parameters.
>>> 
>>> I don't know if we could get away with a single new parameter that could 
>>> carry the value for any SAN type. Something like, { ... 
>>> "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I 
>>> feel like that'd probably be okay but in theory there's the potential for 
>>> confusion of the value across different types. So probably there's a need 
>>> to indicate the SAN type too. Either with more client metadata parameters 
>>> like tls_client_auth_san_uir, tls_client_auth_san_email, 
>>> tls_client_auth_san_ip, etc. or maybe with a structured value of some sort 
>>> like {... "tls_client_auth_san": {"type":"URI", 
>>> "value":"spiffe://trust-domain/path"} ... }. And then deciding which types 
>>> to support and if/how to allow for the extensible types.
>>> 
>>> 
>>> I am far from an authority here, but it is my understanding that one
>>> of the primary drivers in supporting SAN over Subject is that the
>>> values are strongly typed. While some of the advantages gained from
>>> this may be less useful in our own context, I feel that it make sense
>>> to keep the values separate and not overload a single value. Whether
>>> that means dedicated metadata parameters or a structured parameter
>>> value, I am not sure what the tradeoffs would be, but both options
>>> sound suitable to me.
>>> 
>>> Anyway, those are just some thoughts on it. And it'll be discussed more 
>>> today. Suggested/proposed text is always helpful though (even if it's not 
>>> used directly it can help move the conversation forward and/or help 
>>> editor(s) to have prospective wording).
>>> 
>>> 
>>> Great. I will work on some sample text since it sounds like that would
>>> be generally 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

[Torsten Lodderstedt]

Hi Joseph, 

> Am 09.11.2018 um 18:27 schrieb Joseph Heenan :
> 
> Hi Torsten,
> 
> A few comments having just read this afresh:
> 
> 2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given 
> it appears to be permitted?

SHALL is equivalent to MUST, changed it into SHOULD for the reason you gave. 

I also changed other occurrences of SHALL to MUST as it seems people are more 
familiar with this term. 

> 
> I find it a little hard to understand exactly what "avoid any redirects or 
> forwards which can be parameterized by URI query parameters” means 
> (particularly as it comes directly after a paragraph on the redirect_uri and 
> I initially thought it was talking about that. Perhaps something along the 
> lines of “avoid forwarding the user’s browser to a value from a uri query 
> parameter” might be clearer.

Incorporated your text.

> 
> " Clients SHALL ensure to only process “ could just be written ‘Client SHALL 
> only process” I think.

That’s indeed simpler :-)

> 
> 
> 2.1.1:
> 
> "Authorization servers SHALL consider the”  - is ’SHALL consider’ different 
> to ’SHOULD’? Or does it mean something like “SHALL implement at least one 
> countermeasure from <…>”.

That wouldn't work since the text in RFC6819 gives implementors multiple mostly 
complementary measures. But the direction of your proposal makes sense, so I 
added the requirement for the AS to bind every code to a client (already stated 
in RFC6749) and to authenticate the client. Thanks to Dynamic Registration and 
PKCE this is now feasible and it seems to be the most effective mitigation to 
me. I also made the reference to RFC 6819 a SHOULD.

> 
> 3.2.4:
> 
> This says "Authorization codes SHOULD be invalidated by the AS after their 
> first use at the token endpoint”.
> 
> https://tools.ietf.org/html/rfc6749#section-10.5 says:
> 
> "Authorization codes MUST be short lived and single-use.”.
> 

Thanks for pointing this out! 

> Does this "MUST be single-use” not effectively already require the code is 
> invalidated after first use? If so why downgrade this to a “SHOULD”?

You are right. My feeling is single use can turn out to be a really hard to 
implement requirement. That’s why I would like to relax it. Given we now have a 
stronger requirement on client authentication that should be fine. 

Question to the list: what is your implementation experience regarding one time 
use authorization codes?

Thanks for your feedback!

kind regards,
Torsten. 

> 
> 
> Cheers,
> 
> Joseph
> 
> 
>> On 9 Nov 2018, at 09:42, Torsten Lodderstedt  wrote:
>> 
>> Hi all, 
>> 
>> the new revision incorporates the recommendation to use more secure grant 
>> types instead of implicit we agreed to add during the WG session on Monday. 
>> It also has more text around justifications for our recommendation. 
>> Especially, there is a new section 3.6 on access token injection. 
>> 
>> I also posted about this topic on LinkedIn 
>> (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/)
>>  and Medium 
>> (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926)
>> 
>> kind regards,
>> Torsten. 
>> 
>>> Am 09.11.2018 um 09:32 schrieb internet-dra...@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 WG of the IETF.
>>> 
>>>  Title   : OAuth 2.0 Security Best Current Practice
>>>  Authors : Torsten Lodderstedt
>>>John Bradley
>>>Andrey Labunets
>>>Daniel Fett
>>> Filename: draft-ietf-oauth-security-topics-09.txt
>>> Pages   : 35
>>> Date: 2018-11-09
>>> 
>>> Abstract:
>>> This document describes best current security practice for OAuth 2.0.
>>> It updates and extends the OAuth 2.0 Security Threat Model to
>>> incorporate practical experiences gathered since OAuth 2.0 was
>>> published and covers new threats relevant due to the broader
>>> application of OAuth 2.0.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09
>>> https://datatracker.ietf.org/doc/h

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

> Am 08.11.2018 um 22:59 schrieb David Waite :
> 
> PCKE does not resolve any known code injection attacks for SPA public clients.

It can be utilized to detect code injection at the redirect between AS and 
client. The PKCE verifier is bound to user agent that initiated the 
corresponding request. The AS binds the code to the respective PCKE challenge. 
If a code is stolen and injected at a different user agent, the PKCE verifier 
check will fail at the AS (because the client will use the wrong PKCE 
verifier).

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.5






smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

[Torsten Lodderstedt]

Hi all, 

the new revision incorporates the recommendation to use more secure grant types 
instead of implicit we agreed to add during the WG session on Monday. It also 
has more text around justifications for our recommendation. Especially, there 
is a new section 3.6 on access token injection. 

I also posted about this topic on LinkedIn 
(https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/)
 and Medium 
(https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926)

kind regards,
Torsten. 

> Am 09.11.2018 um 09:32 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>    Authors     : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>  Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-09.txt
>   Pages   : 35
>   Date: 2018-11-09
> 
> Abstract:
>   This document describes best current security practice for OAuth 2.0.
>   It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and covers new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth Security Workshop 2019 - Save the Date!

[Torsten Lodderstedt]

Hi all, 

it has become a tradition to conduct an OAuth Security Workshop once a year. 
This time it is taking place March 20–22, 2019 (just before IETF-104 in 
Prague), in Stuttgart/Germany, and is hosted by the Institute of Information 
Security (SEC) at the University of Stuttgart.

And here is the workshop website: https://sec.uni-stuttgart.de/events/osw2019

Stay tuned!

kind regards,
Torsten. 

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

[Torsten Lodderstedt]

Hi all, 

the Financial-grade API WG at the OpenID Foundation has published a mechanism 
for signing and encrypting OAuth authorization responses that I would like to 
bring to your attention. 

The draft https://openid.net//specs/openid-financial-api-jarm-wd-01.html went 
already through Implementations Draft voting. 

I presented the draft in the session today at IETF-103 and perceived positive 
feedback on making this draft usable in a broader OAuth context. For the time 
being we would like the draft to stay in the FAPI WG. If you want to give 
feedback, please do so either here or at the FAPI mailing list 
(http://lists.openid.net/mailman/listinfo/openid-specs-fapi).

kind regards,
Torsten. 

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01

[Torsten Lodderstedt]

Hi all, 

as mentioned during the presentation this morning, I would like to get a 
feeling what the working groups thinks about generalizing 
draft-ietf-oauth-jwt-introspection-response-01 to a mechanism supporting 
requesting and providing JWT responses from the different OAuth endpoints, such 
as token, revocation, client registration, and introspection. 

Please share your thoughts on the list. 

Thanks in advance,
Torsten. 

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi all,

the new revision has an additional section 2.1.2 giving recommendations on 
token replay/injection detection with the implicit grant. Additionally, we also 
uppercased the relevant keywords in section 2 to comply with RFC 2119.

Looking forward for your feedback. 

kind regards,
Torsten. 

> Am 15.10.2018 um 14:50 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>    Authors     : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>  Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-08.txt
>   Pages   : 34
>   Date: 2018-10-15
> 
> Abstract:
>   This document describes best current security practices for OAuth
>   2.0.  It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and covers new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-08
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth WG - Important Dates

[Torsten Lodderstedt]

Hi chairs, 

I would like to present two drafts in Bangkok:

- draft-ietf-oauth-security-topics 
- draft-ietf-oauth-jwt-introspection-response

I would also like to present to the group a new work item being prepared by the 
OpenID Foundation FAPI WG: 
- JWT Secured Authorization Response Mode for OAuth 2.0 
(https://openid.net//specs/openid-financial-api-jarm-wd-01.html) mirrors JAR 
for authorization responses. This might be interesting to the WG.

best regards,
Torsten. 

> Am 10.09.2018 um 20:17 schrieb Rifaat Shekh-Yusef :
> 
> All,
> 
> The following is a subset of the important date for IETF103:
> 
> Important Dates
> IETF 103 : 2018-11-03, Bangkok, TH
> 2018-09-17 (Monday): Early Bird registration and payment cut-off at UTC 23:59.
> 2018-09-21 (Friday): Cut-off date for requests to schedule Working Group 
> Meetings at UTC 23:59.
> 2018-10-05 (Friday): Preliminary Agenda published for comment.
> 
> Notice that the cut-off for early bird registration is a week from now.. 
> (Thanks to Brian for pointing this out)
> 
> The cut-off date for scheduling a WG meeting is less than two weeks from now.
> So, please let us know as soon as possible if you are planning on presenting 
> and which topics you planning on discussing, 
> to help us plan and request enough time to cover these topics.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Torsten Lodderstedt]

Hi Samuel,

thanks for preparing this draft. I‘ve got one question: how would one use it 
for non-reputation? I assume non-reputation would require not only to sign the 
request body but also (at least) data about the target of the request, 
typically a URL + HTTP method. Would one need to include (replicate) this data 
in the JSON object?

kind regards,
Torsten.

> Am 06.09.2018 um 22:20 schrieb Samuel Erdtman :
> 
> Hi,
> 
> A new version has been submitted. It would awesome if we could get some 
> comments on the draft and thoughts about a potential future adoption.
> 
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
> 
> Changes includes the change of canonicalization method and some minor 
> clarifications.
> 
> Best regards
> //Samuel
> 
> 
> 
>> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  wrote:
>> Then I’ll post an update within a ~week.
>> 
>> There is one thing that could make implementing even simpler (from my 
>> experience). That is how to handle multiple signatures. Today the 
>> specification supports sharing of headers between signatures. If signatures 
>> instead are completely independent and put in an array at the top level 
>> cleartext_signature attribute one could just do a minor change to existing 
>> implementations to support cleartext signatures.
>> 
>>> On Wed, 5 Sep 2018 at 15:54, Dave Tonge  wrote:
>>> Hi Samuel,
>>> 
>>> Thanks for the reply, I would definitely be interested in an updated draft.
>>> Both the signing spec and the canonicalization spec seem a lot simpler than 
>>> JSON-LD.
>>> It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
>>> 
>>> Thanks
>>> 
>>> Dave
>>> 
 On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  wrote:
 Hi
 
 As one of the authors of draft-erdtman-jose-cleartext-jws I definitely 
 think this is the way to go. The initial use case was to sign transaction 
 requests and responses, and as was mentioned in previous emails it is very 
 much desirable to not obfuscate the payload with base64 encoding.
 
 The current draft just expired but if we have found interest I would be 
 more than willing to post an update. I was supposed to do so earlier but 
 since it has been hard to find a home for the work (an interested WG) it 
 has not be top of my proirity list. 
 
 With the potential update we (I and the co authors) intended to do some 
 cleanup and one significant change. We think we should move from ES6 
 serialization to canonicalization based on 
 draft-rundgren-json-canonicalization-scheme. After a lot of research and 
 emails we have come to the conclusion that it would be easier to get buy 
 in for this method than to get languages to support ES6 compatible 
 serialization. draft-rundgren-json-canonicalization-scheme has the 
 additional benefit that non-intrusive modifications such as attribute 
 reordering would not make ruin this signature which was the case with ES6 
 serialization (and we could avoid some minor ES6 quirks). 
 
 Implementations for the draft-rundgren-json-canonicalization-scheme 
 canonicalization schema is available in JavaScript, .NET, Java , and 
 Python. Anders is currently putting a lot of effort into the 
 canonicalization to make sure it is stable, and it has been reviewed by 
 several people knowledgeable in JSON.
 
 When it comes to draft-erdtman-jose-cleartext-jws implementations, I have 
 done one in JavaScript (I modified an existing JOSE implementation in a 
 few hours) and Anders has done a Java implementation (at least). The 
 examples in the specification was created and validated with different 
 implementations.
 
 I know canonicalization is a scary thing if you have worked with 
 canonicalization of XML, but I can tell you canonicalization of JSON is 
 not even close to that complex.
 
 Best regards 
 //Samuel Erdtman
 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

[Torsten Lodderstedt]

> Am 29.08.2018 um 15:38 schrieb George Fletcher :
> 
> Couldn't the AS issue a token where the audience restriction is a list? This 
> is true of the id_token spec. 

Sure, it could. That's certainly better than an unconstraint access token. But 
the recommendation in the draft is to restrict tokens to a single server. 

The draft states: „In particular, access tokens SHOULD be restricted to certain 
resource servers, preferably to a single resource server."

> 
> On 8/27/18 2:24 PM, Torsten Lodderstedt wrote:
>> 
>> 
>> Am 27.08..2018 um 11:32 schrieb Vladimir Dzhuvinov :
>> 
>>> Thanks for the update!
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07#section-3.7.1.3
>>> 
>>> Audience restricted access token:
>>> 
>>> In a multi-RS environment with aud-restricted token policy in place, how 
>>> should the AS respond to an authZ request with scope values that belong to 
>>> more than one RS?
>>> 
>> That’s a really good question! 
>> 
>> I see the following options:
>> 1) the AS may abort and require the client to request tokens for different 
>> RSs using multiple authz requests (not cool)
>> 2) the AS mints an access token for one of the resource servers and 
>> indicates this in the scope parameter of the token response. The AS may 
>> additionally issue a refresh token for the complete scope
>> 3) the client could indicate the target RS it wants to interact with in the 
>> first step (e.g. using the resource parameter introduced by the resource 
>> indicators draft). The rest could work like (2)
>> 
>> kinds regards,
>> Torsten..
>>> Vladimir
>>> On 24/08/18 12:57, Torsten Lodderstedt wrote:
>>>> Hi all, 
>>>> 
>>>> I just published a new revision of the OAuth Security BCP. 
>>>> 
>>>> Here is the list of changes:
>>>> * added section on access token privilege restriction based on comments 
>>>> from Johan Peeters
>>>> * incorporated findings of Doug McDorman (e.g. domains used in examples)
>>>> * added section on HTTP status codes for redirects
>>>> 
>>>> kind regards,
>>>> Torsten. 
>>>> 
>>>> 
>>>>> Am 24.08.2018 um 11:51 schrieb internet-dra...@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 WG of the 
>>>>> IETF.
>>>>> 
>>>>>Title   : OAuth 2.0 Security Best Current Practice
>>>>>Authors : Torsten Lodderstedt
>>>>>  John Bradley
>>>>>  Andrey Labunets
>>>>>  Daniel Fett
>>>>>   Filename: draft-ietf-oauth-security-topics-07.txt
>>>>>   Pages   : 33
>>>>>   Date: 2018-08-24
>>>>> 
>>>>> Abstract:
>>>>>   This document describes best current security practices for OAuth
>>>>>   2.0.  It updates and extends the OAuth 2.0 Security Threat Model to
>>>>>   incorporate practical experiences gathered since OAuth 2.0 was
>>>>>   published and covers new threats relevant due to the broader
>>>>>   application of OAuth 2.0.
>>>>> 
>>>>> 
>>>>> The IETF datatracker status page for this draft is:
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>> 
>>>>> 
>>>>> There are also htmlized versions available at:
>>>>> 
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-07
>>>>> 
>>>>> 
>>>>> A diff from the previous version is available at:
>>>>> 
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-07
>>>>> 
>>>>> 
>>>>> 
>>>>> Please note that it may take a couple of minutes from the time of 
>>>>> submission
>>>>> until the htmlized version and diff are available at 
>>>>> tools.ietf.org
>>>>> .
>>>>> 
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> 
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>> 
>>>>> 
>>>>> ___
>>>>> OAuth mailing list
>>>>> 
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> ___
>>>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

[Torsten Lodderstedt]

> Am 27.08.2018 um 11:32 schrieb Vladimir Dzhuvinov :
> 
> Thanks for the update!
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07#section-3.7.1.3
> 
> Audience restricted access token:
> 
> In a multi-RS environment with aud-restricted token policy in place, how 
> should the AS respond to an authZ request with scope values that belong to 
> more than one RS?
> 
That’s a really good question! 

I see the following options:
1) the AS may abort and require the client to request tokens for different RSs 
using multiple authz requests (not cool)
2) the AS mints an access token for one of the resource servers and indicates 
this in the scope parameter of the token response. The AS may additionally 
issue a refresh token for the complete scope
3) the client could indicate the target RS it wants to interact with in the 
first step (e.g. using the resource parameter introduced by the resource 
indicators draft). The rest could work like (2)

kinds regards,
Torsten.
> Vladimir
>> On 24/08/18 12:57, Torsten Lodderstedt wrote:
>> Hi all, 
>> 
>> I just published a new revision of the OAuth Security BCP. 
>> 
>> Here is the list of changes:
>> * added section on access token privilege restriction based on comments from 
>> Johan Peeters
>> * incorporated findings of Doug McDorman (e.g. domains used in examples)
>> * added section on HTTP status codes for redirects
>> 
>> kind regards,
>> Torsten. 
>> 
>>> Am 24.08.2018 um 11:51 schrieb internet-dra...@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 WG of the IETF.
>>> 
>>>Title   : OAuth 2.0 Security Best Current Practice
>>>Authors : Torsten Lodderstedt
>>>  John Bradley
>>>  Andrey Labunets
>>>  Daniel Fett
>>> Filename: draft-ietf-oauth-security-topics-07.txt
>>> Pages   : 33
>>> Date: 2018-08-24
>>> 
>>> Abstract:
>>>   This document describes best current security practices for OAuth
>>>   2.0.  It updates and extends the OAuth 2.0 Security Threat Model to
>>>   incorporate practical experiences gathered since OAuth 2.0 was
>>>   published and covers new threats relevant due to the broader
>>>   application of OAuth 2.0.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-07
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-07
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

[Torsten Lodderstedt]

Hi all, 

I just published a new revision of the OAuth Security BCP. 

Here is the list of changes:
* added section on access token privilege restriction based on comments from 
Johan Peeters
* incorporated findings of Doug McDorman (e.g. domains used in examples)
* added section on HTTP status codes for redirects

kind regards,
Torsten. 

> Am 24.08.2018 um 11:51 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>    Authors     : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>  Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-07.txt
>   Pages   : 33
>   Date: 2018-08-24
> 
> Abstract:
>   This document describes best current security practices for OAuth
>   2.0.  It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and covers new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-jwt-introspection-response-01.txt

[Torsten Lodderstedt]

Hi all,

we just published a new revision of the JWT Introspection Response Draft.

Changes:
* adapted wording to preclude any accept header except "application/jwt" if 
encrypted responses are required
* use registered alg value RS256 for default signing algorithm
* added text on claims in the token introspection response

We are looking forward for your feedback. 

kind regards,
Torsten. 

> Anfang der weitergeleiteten Nachricht:
> 
> Von: internet-dra...@ietf.org
> Betreff: [OAUTH-WG] I-D Action: 
> draft-ietf-oauth-jwt-introspection-response-01.txt
> Datum: 22. August 2018 um 21:09:10 MESZ
> An: 
> Kopie: oauth@ietf.org
> Antwort an: 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 WG of the IETF.
> 
>Title   : JWT Response for OAuth Token Introspection
>Authors : Torsten Lodderstedt
>  Vladimir Dzhuvinov
>   Filename: draft-ietf-oauth-jwt-introspection-response-01.txt
>   Pages   : 11
>   Date: 2018-08-22
> 
> Abstract:
>   This draft proposes an additional JSON Web Token (JWT) based response
>   for OAuth 2.0 Token Introspection.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-01
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

[Torsten Lodderstedt]

Hi Brian,

here are my text proposals (and a comments):

- Section 2, resource parameter definition 

„It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986],
  and MUST NOT include a query or fragment component.“

Why does the draft preclude query components? 

- I would propose to add the following text at the end of Section 2 (before the 
last paragraph):

"The authorization server SHOULD adapt the scope value associated 
with an access token to the value the respective resource(s) is 
able to process and needs to know. This further improves privacy as
scope values give an indication of what services the resource owner
uses and it improves security as scope values may contain confidential
data. The authorization server MUST indicate the access token’s 
effective scope to the client in the „scope" response value.

The authorization server MUST ensure the client is able to obtain other sub 
sets of 
the underlying grant or the whole scope in subsequent transactions. In case of 
a confidential client, the authorization server might associate the grant with 
its client_id. In case of a public client, a refresh token could be used to 
represent
the grant."

I think it would make sense to establish the link to William‘s draft, as I see
common patterns re grant handling.

- I’m proposing to add the following text re resource indicators and the code 
response type (potentially in a new section).

„The authorization server MAY require clients to specify the resource(s) they 
intend to 
access in requests to the authorization endpoint with response type „code". The 
authorization server might use this data to inform the user about the resources
the client is going to access on her behalf, to meet policy decision (e.g. 
refuse the 
request due to unknown resources), and determine the set of 
resources that can be used in subsequent access token requests.“

kind regards,
Torsten. 

> Am 04.08.2018 um 05:39 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : Resource Indicators for OAuth 2.0
>Authors : Brian Campbell
>  John Bradley
>  Hannes Tschofenig
>   Filename: draft-ietf-oauth-resource-indicators-00.txt
>   Pages   : 8
>   Date: 2018-08-03
> 
> Abstract:
>   This straw-man specification defines an extension to The OAuth 2.0
>   Authorization Framework that enables the client and authorization
>   server to more explicitly to communicate about the protected
>   resource(s) to be accessed.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> 
> We are building up the scheme. One banking group is deployed.
> 
>> 
>> Today, a separate flow us required for each RS, correct?
> 
> We support combined flows because this is a key requirement for us. But this 
> comes at a price: we cannot tightly audience restrict our tokens. We use 
> handles and Introspection to ensure every RS only gets to know the data it 
> needs to know. And we must use sender constraint tokens in order to prevent 
> token leakage. Having an interoperable way to obtain structured and audience 
> restricted access tokens would simply development, reduce coupling between AS 
> & RS and improve performance.

I forgot to mention, a deployment supporting strict resource server specific 
audience restriction with structured access tokens is in place at Deutsche 
Telekom for years now ( even predating OAuth 2.0). As the only drawback, 
encoding of resource servers in scopes and refresh token handling to obtain 
RS-specific access tokens is proprietary.

> 
>> 
>> In the future, you would like the client to ask for multiple resources that 
>> are managed by the same AS, correct?
>> 
>> 
>>> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt 
>>>  wrote:
>>> For every bank (and their customers) there is a set of services run by the 
>>> bank or other entities, which rely on the AS of the particular bank for 
>>> authorization. In some cases, a service may bring its own AS to the party 
>>> (due to technical restrictionions). So an RP binding to a certain 
>>> bank-specific service ecosystem needs to determine which AS every RS relies 
>>> on. Authorization requests for RS relying on the same AS (the bank) can be 
>>> combined into s single request/flow resulting in an optimized UX.
>>> 
>>>> Am 24.07.2018 um 22:21 schrieb Dick Hardt :
>>>> 
>>>> I'm trying to understand the use case. 
>>>> 
>>>> It still is vague. Are you saying that each of these is run by a different 
>>>> entity, but all trust the bank as the authorization server to manage if 
>>>> the user has granted permission to use the resource rather than managing 
>>>> it themselves? 
>>>> 
>>>> account information, payment initiation, identity, and electronic 
>>>> signature 
>>>> 
>>>>>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt 
>>>>>>  wrote:
>>>>>> 
>>>>>> And who is the AS?
>>>>> 
>>>>> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the 
>>>>> central AS/IDP. 
>>>>> 
>>>>> Why are you asking?
>>>>> 
>>>>>> 
>>>>>>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>> 
>>>>>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>>>>>>> 
>>>>>>>> In your examples, are these the same AS?
>>>>>>> 
>>>>>>> yes
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>>>>>>>>  wrote:
>>>>>>>>> Hi Dick,
>>>>>>>>> 
>>>>>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>>>>>>>>> > 
>>>>>>>>> > Entering in an email address that resolves to a resource makes 
>>>>>>>>> > sense. It would seem that even if this was email, calendar etc. -- 
>>>>>>>>> > that those would be different scopes for the same AS, not even 
>>>>>>>>> > different resources. That is how all of Google, Microsoft work 
>>>>>>>>> > today.
>>>>>>>>> 
>>>>>>>>> I don’t know how those services work re OAuth resources. To me it’s 
>>>>>>>>> not obvious why one should make all those services a single OAuth 
>>>>>>>>> resource. I assume the fact OAuth as it is specified today has no 
>>>>>>>>> concept of identifying a resource and audience restrict an access 
>>>>>>>>> token led to designs not utilizing audience restriction. 
>>>>>>>>> 
>>>>>>>>> Can any of the Google or Microsoft on this list representatives 
>>>>>>>>> please comment?
>>>>>>>>> 
>>>>>>>>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>>>>>>>>> further services were treated as different resources and clients 
>>>>>>>>> needed different (audience restricted) access tokens to use it.
>>>>>>>>> 
>>>>>>>>> In case of YES, the locations of a user’s services for account 
>>>>>>>>> information, payment initiation, identity, and electronic signature 
>>>>>>>>> are determined based on her bank affiliation (bank identification 
>>>>>>>>> code). In general, each of these services may be provided/operated by 
>>>>>>>>> a different entity and exposed at completely different endpoints 
>>>>>>>>> (even different DNS domains).
>>>>>>>>> 
>>>>>>>>> kind regards,
>>>>>>>>> Torsten.
>>>>>> 
>>>> 
>> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> Am 24.07.2018 um 22:51 schrieb Dick Hardt :
> 
> Ok. I think I understand the use case now. Would you confirm?
> 
> These are deployed today, correct?

We are building up the scheme. One banking group is deployed.

> 
> Today, a separate flow us required for each RS, correct?

We support combined flows because this is a key requirement for us. But this 
comes at a price: we cannot tightly audience restrict our tokens. We use 
handles and Introspection to ensure every RS only gets to know the data it 
needs to know. And we must use sender constraint tokens in order to prevent 
token leakage. Having an interoperable way to obtain structured and audience 
restricted access tokens would simply development, reduce coupling between AS & 
RS and improve performance.

> 
> In the future, you would like the client to ask for multiple resources that 
> are managed by the same AS, correct?
> 
> 
>> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt 
>>  wrote:
>> For every bank (and their customers) there is a set of services run by the 
>> bank or other entities, which rely on the AS of the particular bank for 
>> authorization. In some cases, a service may bring its own AS to the party 
>> (due to technical restrictionions). So an RP binding to a certain 
>> bank-specific service ecosystem needs to determine which AS every RS relies 
>> on. Authorization requests for RS relying on the same AS (the bank) can be 
>> combined into s single request/flow resulting in an optimized UX.
>> 
>>> Am 24.07.2018 um 22:21 schrieb Dick Hardt :
>>> 
>>> I'm trying to understand the use case. 
>>> 
>>> It still is vague. Are you saying that each of these is run by a different 
>>> entity, but all trust the bank as the authorization server to manage if the 
>>> user has granted permission to use the resource rather than managing it 
>>> themselves? 
>>> 
>>> account information, payment initiation, identity, and electronic signature 
>>> 
>>>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt 
>>>>  wrote:
>>>> 
>>>>> And who is the AS?
>>>> 
>>>> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the 
>>>> central AS/IDP. 
>>>> 
>>>> Why are you asking?
>>>> 
>>>>> 
>>>>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
>>>>>>  wrote:
>>>>>> 
>>>>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>>>>>> 
>>>>>>> In your examples, are these the same AS?
>>>>>> 
>>>>>> yes
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>>>>>>>  wrote:
>>>>>>>> Hi Dick,
>>>>>>>> 
>>>>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>>>>>>>> > 
>>>>>>>> > Entering in an email address that resolves to a resource makes 
>>>>>>>> > sense. It would seem that even if this was email, calendar etc. -- 
>>>>>>>> > that those would be different scopes for the same AS, not even 
>>>>>>>> > different resources. That is how all of Google, Microsoft work today.
>>>>>>>> 
>>>>>>>> I don’t know how those services work re OAuth resources. To me it’s 
>>>>>>>> not obvious why one should make all those services a single OAuth 
>>>>>>>> resource. I assume the fact OAuth as it is specified today has no 
>>>>>>>> concept of identifying a resource and audience restrict an access 
>>>>>>>> token led to designs not utilizing audience restriction. 
>>>>>>>> 
>>>>>>>> Can any of the Google or Microsoft on this list representatives please 
>>>>>>>> comment?
>>>>>>>> 
>>>>>>>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>>>>>>>> further services were treated as different resources and clients 
>>>>>>>> needed different (audience restricted) access tokens to use it.
>>>>>>>> 
>>>>>>>> In case of YES, the locations of a user’s services for account 
>>>>>>>> information, payment initiation, identity, and electronic signature 
>>>>>>>> are determined based on her bank affiliation (bank identification 
>>>>>>>> code). In general, each of these services may be provided/operated by 
>>>>>>>> a different entity and exposed at completely different endpoints (even 
>>>>>>>> different DNS domains).
>>>>>>>> 
>>>>>>>> kind regards,
>>>>>>>> Torsten.
>>>>> 
>>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

For every bank (and their customers) there is a set of services run by the bank 
or other entities, which rely on the AS of the particular bank for 
authorization. In some cases, a service may bring its own AS to the party (due 
to technical restrictionions). So an RP binding to a certain bank-specific 
service ecosystem needs to determine which AS every RS relies on. Authorization 
requests for RS relying on the same AS (the bank) can be combined into s single 
request/flow resulting in an optimized UX.

> Am 24.07.2018 um 22:21 schrieb Dick Hardt :
> 
> I'm trying to understand the use case. 
> 
> It still is vague. Are you saying that each of these is run by a different 
> entity, but all trust the bank as the authorization server to manage if the 
> user has granted permission to use the resource rather than managing it 
> themselves? 
> 
> account information, payment initiation, identity, and electronic signature 
> 
>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt 
>>  wrote:
>> 
>>> And who is the AS?
>> 
>> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the 
>> central AS/IDP. 
>> 
>> Why are you asking?
>> 
>>> 
>>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
>>>>  wrote:
>>>> 
>>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>>>> 
>>>>> In your examples, are these the same AS?
>>>> 
>>>> yes
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>>>>>  wrote:
>>>>>> Hi Dick,
>>>>>> 
>>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>>>>>> > 
>>>>>> > Entering in an email address that resolves to a resource makes sense. 
>>>>>> > It would seem that even if this was email, calendar etc. -- that those 
>>>>>> > would be different scopes for the same AS, not even different 
>>>>>> > resources. That is how all of Google, Microsoft work today.
>>>>>> 
>>>>>> I don’t know how those services work re OAuth resources. To me it’s not 
>>>>>> obvious why one should make all those services a single OAuth resource. 
>>>>>> I assume the fact OAuth as it is specified today has no concept of 
>>>>>> identifying a resource and audience restrict an access token led to 
>>>>>> designs not utilizing audience restriction. 
>>>>>> 
>>>>>> Can any of the Google or Microsoft on this list representatives please 
>>>>>> comment?
>>>>>> 
>>>>>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>>>>>> further services were treated as different resources and clients needed 
>>>>>> different (audience restricted) access tokens to use it.
>>>>>> 
>>>>>> In case of YES, the locations of a user’s services for account 
>>>>>> information, payment initiation, identity, and electronic signature are 
>>>>>> determined based on her bank affiliation (bank identification code). In 
>>>>>> general, each of these services may be provided/operated by a different 
>>>>>> entity and exposed at completely different endpoints (even different DNS 
>>>>>> domains).
>>>>>> 
>>>>>> kind regards,
>>>>>> Torsten.
>>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> And who is the AS?

In case of yes, it’s typically the bank. At Deutsche Telekom, it is the central 
AS/IDP. 

Why are you asking?

> 
>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
>>  wrote:
>> 
>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>> 
>>> In your examples, are these the same AS?
>> 
>> yes
>> 
>>> 
>>> 
>>> 
>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>>>  wrote:
>>>> Hi Dick,
>>>> 
>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>>>> > 
>>>> > Entering in an email address that resolves to a resource makes sense. It 
>>>> > would seem that even if this was email, calendar etc. -- that those 
>>>> > would be different scopes for the same AS, not even different resources. 
>>>> > That is how all of Google, Microsoft work today.
>>>> 
>>>> I don’t know how those services work re OAuth resources. To me it’s not 
>>>> obvious why one should make all those services a single OAuth resource. I 
>>>> assume the fact OAuth as it is specified today has no concept of 
>>>> identifying a resource and audience restrict an access token led to 
>>>> designs not utilizing audience restriction. 
>>>> 
>>>> Can any of the Google or Microsoft on this list representatives please 
>>>> comment?
>>>> 
>>>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>>>> further services were treated as different resources and clients needed 
>>>> different (audience restricted) access tokens to use it.
>>>> 
>>>> In case of YES, the locations of a user’s services for account 
>>>> information, payment initiation, identity, and electronic signature are 
>>>> determined based on her bank affiliation (bank identification code). In 
>>>> general, each of these services may be provided/operated by a different 
>>>> entity and exposed at completely different endpoints (even different DNS 
>>>> domains).
>>>> 
>>>> kind regards,
>>>> Torsten.
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
> 
> In your examples, are these the same AS?

yes

> 
> 
> 
>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>  wrote:
>> Hi Dick,
>> 
>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>> > 
>> > Entering in an email address that resolves to a resource makes sense. It 
>> > would seem that even if this was email, calendar etc. -- that those would 
>> > be different scopes for the same AS, not even different resources. That is 
>> > how all of Google, Microsoft work today.
>> 
>> I don’t know how those services work re OAuth resources. To me it’s not 
>> obvious why one should make all those services a single OAuth resource. I 
>> assume the fact OAuth as it is specified today has no concept of identifying 
>> a resource and audience restrict an access token led to designs not 
>> utilizing audience restriction. 
>> 
>> Can any of the Google or Microsoft on this list representatives please 
>> comment?
>> 
>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>> further services were treated as different resources and clients needed 
>> different (audience restricted) access tokens to use it.
>> 
>> In case of YES, the locations of a user’s services for account information, 
>> payment initiation, identity, and electronic signature are determined based 
>> on her bank affiliation (bank identification code). In general, each of 
>> these services may be provided/operated by a different entity and exposed at 
>> completely different endpoints (even different DNS domains).
>> 
>> kind regards,
>> Torsten.


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt :
> 
> Entering in an email address that resolves to a resource makes sense. It 
> would seem that even if this was email, calendar etc. -- that those would be 
> different scopes for the same AS, not even different resources. That is how 
> all of Google, Microsoft work today.

I don’t know how those services work re OAuth resources. To me it’s not obvious 
why one should make all those services a single OAuth resource. I assume the 
fact OAuth as it is specified today has no concept of identifying a resource 
and audience restrict an access token led to designs not utilizing audience 
restriction. 

Can any of the Google or Microsoft on this list representatives please comment?

In deployments I‘m familiar with email, calendar, contacts, cloud and further 
services were treated as different resources and clients needed different 
(audience restricted) access tokens to use it.

In case of YES, the locations of a user’s services for account information, 
payment initiation, identity, and electronic signature are determined based on 
her bank affiliation (bank identification code). In general, each of these 
services may be provided/operated by a different entity and exposed at 
completely different endpoints (even different DNS domains).

kind regards,
Torsten.

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10

[Torsten Lodderstedt]

Hi Rifaat,

Berlin Group‘s Nextgen PSD2 Spec 
(https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf) 
also refers to mTLS.

kind regards,
Torsten.

> Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef :
> 
> All,
> 
> The following is the shepherd write-up for the drafts-ietf-oauth-mtls-10 
> document:
> https://datahttps://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/
> 
> Please, take a look and let us know if you have any comments.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
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"

[Torsten Lodderstedt]

Hi Mark,
> Am 20.07.2018 um 17:47 schrieb Mark Dobrinic :
> 
> I +1 this,

thanks

> 
> but at the same time, I'm wondering what happened with the argument that
> this should be solved by Token Exchange instead of Introspect?

We presented two use case in London, (1) providing evidence for the RS’s audit 
log and (2) providing/transforming tokens by a reverse proxy in front of a 
resource server.

The WG advised us to consider token exchange for (2) so the current draft only 
addresses (1).

kind regards,
Torsten.

> 
> Cheers!
> 
> Mark
> 
> 
>> On 20/07/18 17:39, Phil Hunt wrote:
>> +1 adoption
>> 
>> I have always been concerned about clients doing introspection. Use of
>> jwt helps because responses further restricted rather than less (jwe). 
>> 
>> Phil
>> 
>> On Jul 20, 2018, at 7:25 AM, Rob Otto
>> > > wrote:
>> 
>>> I support this as well 
>>> 
>>> On Fri, 20 Jul 2018 at 15:22, Brian Campbell
>>> >> > wrote:
>>> 
>>>+1
>>> 
>>>On Thu, Jul 19, 2018 at 1:51 PM, William Denniss
>>>>>> wrote:
>>> 
>>>I support adoption of this document by the working group.
>>> 
>>> 
>>>On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef
>>>mailto:rifaat.i...@gmail.com>> wrote:
>>> 
>>>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
>>> 
>>> 
>>> 
>>>___
>>>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./___
>>>OAuth mailing list
>>>OAuth@ietf.org 
>>>https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> -- 
>>> Ping Identity
>>> 
>>> Rob Otto
>>> EMEA Field CTO/Solutions Architect
>>> roberto...@pingidentity.com 
>>> 
>>> c: +44 (0) 777 135 6092
>>> 
>>> Connect with us:Glassdoor logo
>>> 
>>> LinkedIn logo  twitter logo
>>> facebook logo
>>> youtube logo
>>> Google+ logo
>>>  Blog logo
>>> 
>>> 
>>> 
>>> 
>>> /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./
>>> ___
>>> 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 Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

Am 19.07.2018 um 15:46 schrieb Dick Hardt :

>> I think any scenario with multiple resource servers relying on the same AS 
>> for authorization where the client acts on behalf of the resource owner 
>> qualifies for grant type code and distributed OAuth. 
>> 
>> Let’s assume a user wants to authorize a client for access to her cloud 
>> storage, email account and contacts when setting app the respective app.
> 
> Would you walk me through the user experience that happened for the client to 
> do discovery on these three resources? In other words, what did the user do 
> to get the client to call the resource and get back the 401 response?

I would assume the user enters the URLs or identifies the respective service 
providers in the app (e.g. by entering her email address). The client then 
sends an initial request as described in your draft and gets back the 401.

Doing so for several resources will give the client the AS URL for all involved 
resources. If the client compares the iss claims it will figure our all 
resources are protected by the same AS and can authorize access via a single 
authz code grant flow.

kind regards,
Torsten.

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi Dick,

> Am 20.07.2018 um 19:46 schrieb Dick Hardt :
> 
> There are a few places where multiple resources could be used:
> 
> One is in the code flow where it is desirable to optimize the user experience 
> so that the user is granting authorization once, and not multiple times. 
> 

I agree. That’s the reason why I’m advocating multiple resource.

> The second is in the access token request, which leads to the third instance, 
> which is in the access token. If an access token is being returned for each 
> resource, then making a single request is simpler, it seems to complicate the 
> interface more.

I agree.

> 
> If we want to have audience constrained access tokens, then it is safer to 
> have only one resource in the access token - otherwise each resource can use 
> the access token to access the other resources.

Yes and no. Yes because it’s safer to use tightly audience restricted access 
tokens.

No because token binding or cert-bound access tokens can prevent abuse in such 
a case.

> 
> All of these examples assume that it is a single AS. Supporting multiple AS 
> in a single request seems super complicated and wrought with security and 
> trust issues.

I don’t see a use case for multiple AS (yet ;-).

kind regards,
Torsten.
> 
> 
> 
> 
>> On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones 
>>  wrote:
>> While I agree that a single requested resource is the common case, enough 
>> people have spoken up with a need for multiple requested resources over the 
>> years that I think everyone will be better served by leaving the ability to 
>> specify multiple requested resources in the specification.
>> 
>>  
>> 
>>-- Mike
>> 
>>  
>> 
>> From: OAuth  On Behalf Of Brian Campbell
>> Sent: Friday, July 20, 2018 10:18 AM
>> To: Filip Skokan 
>> 
>> 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
>> 2.0"
>>  
>> 
>> The current draft does allow multiple "resource" parameters. However, there 
>> seemed to be consensus in the WG meeting yesterday that only a single 
>> "resource" parameter was preferable and that a client could obtain an access 
>> token per resource  (likely using a refresh token). I'm personally 
>> sympathetic to that point. But maybe it's too restrictive. I would like to 
>> see some more text about the complexity implications of multiple "resource" 
>> parameters and perhaps some discouragement of doing so. I believe logical 
>> names are more potentially useful in an STS framework like token exchange 
>> but should be out of scope for this work.  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan  wrote:
>> 
>> Hi Torsten,
>> 
>>  
>> 
>> > Multiple "resource" parameters may be used to indicate that the issued 
>> > token is intended to be used at multiple resource servers.
>> 
>>  
>> 
>> That's already in. Furthermore what about logical names for target services? 
>> Like was added in -03 of token exchange?
>> 
>> 
>> 
>> Best,
>> Filip Skokan
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt 
>>  wrote:
>> 
>> I support adoption of this document.
>> 
>>  
>> 
>> I would like to point out (again) a single resource is not sufficient for 
>> most use cases I implemented in the last couple if years. I‘m advocating for 
>> enhancing the draft to support multiple resources and a clear definition of 
>> the relationship between resource(s) and scope.
>> 
>> 
>> Am 20.07.2018 um 08:20 schrieb n-sakimura :
>> 
>> +1
>> 
>>  
>> 
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
>> Sent: Friday, July 20, 2018 7:42 AM
>> To: Rifaat Shekh-Yusef 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
>> 2.0"
>> 
>>  
>> 
>> I support adoption of this document.
>> 
>>  
>> 
>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef  
>> wrote:
>> 
>> Hi all,
>> 
>> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' 
>> document
>> following the positive call for adoption at the Montreal IETF meeting.
>> 
>> Here is the docum

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

[Torsten Lodderstedt]

> Am 20.07.2018 um 16:06 schrieb 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

Hi Tony,

I think this an issue for introspection in general and not specific to our 
extension.

If the token content needs to be kept confidential then the AS MUST 
authenticate the caller of the Introspection endpoint and apply an suitable 
authz policy. This is possible with Token Introspection and with our draft as 
well. 

Additionally, our draft allows to encrypt the token response, adding an extra 
layer of defense. 

kind regards,
Torsten.

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


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

I support adoption of this document.

I would like to point out (again) a single resource is not sufficient for most 
use cases I implemented in the last couple if years. I‘m advocating for 
enhancing the draft to support multiple resources and a clear definition of the 
relationship between resource(s) and scope.

> Am 20.07.2018 um 08:20 schrieb n-sakimura :
> 
> +1
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, July 20, 2018 7:42 AM
> To: Rifaat Shekh-Yusef 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
> 2.0"
>  
> I support adoption of this document.
>  
> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef  
> wrote:
> Hi all,
> 
> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' 
> document
> following the positive call for adoption at the Montreal IETF meeting.
> 
> Here is the document:
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
> 
> 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,
> Rifaat
> 
> ___
> 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.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

[Torsten Lodderstedt]

+1

> Am 20.07.2018 um 08:21 schrieb n-sakimura :
> 
> And if it were not obvious, YES J
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt
> Sent: Friday, July 20, 2018 6:12 AM
> To: Rifaat Shekh-Yusef 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"
>  
> I'm supportive. :)
>  
> On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef  
> wrote:
> Hi all,
>  
> This is the call for adoption of the 'Distributed OAuth' document
> following the positive call for adoption at the Montreal IETF meeting.
>  
> Here is the document:
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>  
> 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
> 
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

>  
>> 
>> Section 3: 
>> Don’t you think it could be a useful information to have the resource URI 
>> available in the authorization flow?I would assume it could have some 
>> additional meaning to the AS and could also be the context of the scope.
> 
> I'm assuming you are referring to the Authorization Code Grant. Good call out 
> that the resource URI would be useful in the redirect. 
> 
> The use cases that I have been working with have all been Client Credential 
> Grants
> 
> I currently don't know of a real world use case for the Authorization Code 
> Grant for Distributed OAuth.

I think any scenario with multiple resource servers relying on the same AS for 
authorization where the client acts on behalf of the resource owner qualifies 
for grant type code and distributed OAuth. 

Let’s assume a user wants to authorize a client for access to her cloud 
storage, email account and contacts when setting app the respective app.

One would use the code grant type for that use case. And having the resource 
URLs in the authorization flow would allow the AS to further determine the 
context of the requested authorization.

Even more important, the AS could restrict the access tokens for use at this 
URIs only. At best, the AS would allow the client to obtain different access 
tokens for any of the involved resource servers, each of them tailored to the 
needs of the particular RS (content) and bound to it (aud, token binding, ...).

In the YES context, we have several different services/resources, which can be 
combined in a single authorization transaction, e.g. initiation of a payment 
and creating an electronic signature.

In all solutions I have seen or designed in the past, the resource server was 
either carried in the scope parameter or implicitly determined from the scope 
values (see OIDC). Making it explicit would result in an interoperable approach 
to represent this information and use it to tighten up OAuth security and 
privacy (token binding, audience restriction).

kind regards,
Torsten.

>  
>> 
>> Section 4: 
>> I think the client MUST authenticate using a PoP (asymmetric crypto based) 
>> mechanisms due to the attack angle given in 6.3
>> Did you intentionally restricted the draft to single resources?
> 
> yes
>  
>> I would desire support for an integrated UI flow for authorizing access to 
>> multiple resources at once. This makes sense in multi-service deployments.
> 
> It could be. Would be great to get some real use cases for that in an 
> Authorization Code Grant.
>  
>> 
>> Section 6.1. 
>> I suggest you also refer to 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#section-3.7 
>> for a comprehensive discussion of this threat..
> 
> Thanks
>  
>> 
>> kind regards,
>> Torsten.   
>> 
>> 
>> > Am 12.06.2018 um 21:28 schrieb Dick Hardt :
>> > 
>> > Hey OAuth WG
>> > 
>> > I have worked with Nat and Brian to merge our concepts and those are 
>> > captured in the updated draft.
>> > 
>> > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>> > 
>> > We are hopeful the WG will adopt this draft as a WG document.
>> > 
>> > Any comments and feedback are welcome!
>> > 
>> > /Dick
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

[Torsten Lodderstedt]

Hi William, 

I think it would make sense to add AS metadata fields, which the AS can use to 
advertise support for include_granted_scopes and existing_grant.

kind regards,
Torsten. 

> Am 17.07.2018 um 19:33 schrieb William Denniss :
> 
> Hi Torsten,
> 
> On Tue, Jul 17, 2018 at 7:57 AM, Torsten Lodderstedt 
>  wrote:
> Hi William, 
> 
> please find below my review feedback.
> 
> First of all, I think you managed to come up with the minimal extension 
> needed to address a very relevant use case. Thanks!
> 
> Glad you like it! Thanks for reviewing.
>  
> - Section 5, last paragraph. 
> 
> "the new refresh token issued in the Access Token Response (Section 4.1.4 of 
> ) SHOULD include authorization for the scopes in the previous grant.“
> 
> Wouldn’t it be better to make that a MUST? Otherwise the client must assume 
> the AS decides to not include all previously granted scopes, which in turn 
> means the client must keep older grants (and hope the AS dd not automatically 
> revolve it).
> 
> I was torn about this. From a protocol perspective you're not implementing 
> the protocol if you don't do that, so it should be a MUST. However, we need 
> to be careful that we defer to the provider when it comes to what 
> authorization is included as this is always their discretion.  I'll think of 
> a better way to word this so that it can be a MUST while still not limiting 
> the provider's discretion.
>  
> 
> - Section 6.1.1
> 
> The section describes how a client should handle denial for incremental 
> authorizations. How is the AS supposed to handle it? From the text one could 
> deduce the AS should not discard any pre-existing granted scopes. Is that 
> correct? Would it make sense to explicitly state that?
> 
> Good point. That section is mostly talking about the client, I'll add a 
> section for the server. I agree, the normal behavior would not be to revoke 
> previously granted scopes (which is how Google implements it).
> 
> Best,
> William
> 
> 
> > Am 28.06.2018 um 22:14 schrieb internet-dra...@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 WG of the IETF.
> > 
> >Title   : OAuth 2.0 Incremental Authorization
> >Author  : William Denniss
> >   Filename: draft-ietf-oauth-incremental-authz-00.txt
> >   Pages   : 8
> >   Date: 2018-06-28
> > 
> > Abstract:
> >   OAuth 2.0 authorization requests that include every scope the client
> >   might ever need can result in over-scoped authorization and a sub-
> >   optimal end-user consent experience.  This specification enhances the
> >   OAuth 2.0 authorization protocol by adding incremental authorization,
> >   the ability to request specific authorization scopes as needed, when
> >   they're needed, removing the requirement to request every possible
> >   scope that might be needed upfront.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-00
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

I like the draft! It puts together some best practices relevant for dynamic 
OAuth in a reasonable way.

Some comments: 

Section 2: 
I appreciate the idea to let the resource determine its resource URI (later 
used as aud of the access token). This will allow the RS to segment and group 
its resources as needed.

Section 3: 
Don’t you think it could be a useful information to have the resource URI 
available in the authorization flow?I would assume it could have some 
additional meaning to the AS and could also be the context of the scope.

Section 4: 
I think the client MUST authenticate using a PoP (asymmetric crypto based) 
mechanisms due to the attack angle given in 6.3
Did you intentionally restricted the draft to single resources? I would desire 
support for an integrated UI flow for authorizing access to multiple resources 
at once. This makes sense in multi-service deployments.

Section 6.1. 
I suggest you also refer to 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#section-3.7 for 
a comprehensive discussion of this threat.

kind regards,
Torsten.   


> Am 12.06.2018 um 21:28 schrieb Dick Hardt :
> 
> Hey OAuth WG
> 
> I have worked with Nat and Brian to merge our concepts and those are captured 
> in the updated draft.
> 
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
> 
> We are hopeful the WG will adopt this draft as a WG document.
> 
> Any comments and feedback are welcome!
> 
> /Dick
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt

[Torsten Lodderstedt]

Hi Dick,

I gave you draft a read and came up with the following questions:

Section 2: How does Party A know it is supposed to conduct a reciprocal OAuth 
flow if Party B does not indicate so in the authorization response?

Section 3

Party A is supposed to call the token endpoint of Party B using an 
authorization code generated by Party A. How does Party B interpret this code? 
Or does it just send this code back to Party A to obtain its access token for A?

Party B uses the access token issued to Party A in the first part of the flow 
(ordinary OAuth code flow) to identify the respective user account with Party 
B. Since the AS consumes its access token as an RS, does Party A need to 
include a certain scope in the code flow request in order to enable this part 
of the flow?

How is the AS of Party B supposed to determine the token endpoint of Party A’s 
AS?

I think a figure of the overall process would help to understand the concept. 

kind regards,
Torsten. 

> Am 24.05.2018 um 22:28 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : Reciprocal OAuth
>Author  : Dick Hardt
>   Filename: draft-ietf-oauth-reciprocal-00.txt
>   Pages   : 4
>   Date: 2018-05-24
> 
> Abstract:
>   There are times when a user has a pair of protected resources that
>   would like to request access to each other.  While OAuth flows
>   typically enable the user to grant a client access to a protected
>   resource, granting the inverse access requires an additional flow.
>   Reciprocal OAuth enables a more seamless experience for the user to
>   grant access to a pair of protected resources.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

[Torsten Lodderstedt]

Hi William, 

please find below my review feedback.

First of all, I think you managed to come up with the minimal extension needed 
to address a very relevant use case. Thanks!

- Section 5, last paragraph. 

"the new refresh token issued in the Access Token Response (Section 4.1.4 of ) 
SHOULD include authorization for the scopes in the previous grant.“

Wouldn’t it be better to make that a MUST? Otherwise the client must assume the 
AS decides to not include all previously granted scopes, which in turn means 
the client must keep older grants (and hope the AS dd not automatically revolve 
it).

- Section 6.1.1

The section describes how a client should handle denial for incremental 
authorizations. How is the AS supposed to handle it? From the text one could 
deduce the AS should not discard any pre-existing granted scopes. Is that 
correct? Would it make sense to explicitly state that?

kind regards,
Torsten. 


> Am 28.06.2018 um 22:14 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Incremental Authorization
>Author  : William Denniss
>   Filename: draft-ietf-oauth-incremental-authz-00.txt
>   Pages   : 8
>   Date: 2018-06-28
> 
> Abstract:
>   OAuth 2.0 authorization requests that include every scope the client
>   might ever need can result in over-scoped authorization and a sub-
>   optimal end-user consent experience.  This specification enhances the
>   OAuth 2.0 authorization protocol by adding incremental authorization,
>   the ability to request specific authorization scopes as needed, when
>   they're needed, removing the requirement to request every possible
>   scope that might be needed upfront.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS - IPR Disclosure

[Torsten Lodderstedt]

I’m not aware of any IPR re the OAuth mTLS draft.

> Am 17.07.2018 um 16:11 schrieb Nat Sakimura :
> 
> Not that I am aware of. 
> 
> On Tue, Jul 17, 2018 at 11:06 PM Rifaat Shekh-Yusef  
> wrote:
> Authors,
> 
> As part of the write-up for the OAuth MTLS document, we need an IPR 
> disclosure from all of you..
> 
> Are you aware of any IPR related to the following OAuth MTLS document?
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
> 
> Regards,
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414

[Torsten Lodderstedt]

Congratulations!

> Am 28.06.2018 um 18:15 schrieb William Denniss 
> :
> 
> Congratulations!
> 
> Really glad that we have an RFC specifying how servers should provide their 
> configuration data in machine readable form. Helps with developer experience 
> (less manual configuration), as well as mitigating mix-up attacks (better 
> association of related endpoints), amongst other benefits.
> 
> I'm happy to say that the AppAuth clients support RFC 8414, through discovery 
> methods that take a complete URL, in addition to the issuer-based ones 
> designed for OIDC usage.
> 
> 
>> On Thu, Jun 28, 2018 at 3:54 PM, Mike Jones 
>>  wrote:
>> The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414..  
>> The abstract describes the specification as:
>> 
>>  
>> 
>> This specification defines a metadata format that an OAuth 2.0 client can 
>> use to obtain the information needed to interact with an OAuth 2.0 
>> authorization server, including its endpoint locations and authorization 
>> server capabilities.
>> 
>>  
>> 
>> The specification defines a JSON metadata representation for OAuth 2.0 
>> authorization servers that is compatible with OpenID Connect Discovery 1.0.  
>> This specification is a true instance of standardizing existing practice.  
>> OAuth 2.0 deployments have been using the OpenID Connect metadata format to 
>> describe their endpoints and capabilities for years.  This RFC makes this 
>> existing practice a standard.
>> 
>>  
>> 
>> Having a standard OAuth metadata format makes it easier for OAuth clients to 
>> configure connections to OAuth authorization servers.  See 
>> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata
>>  for the initial set of registered metadata values.
>> 
>>  
>> 
>> Thanks to all of you who helped make this standard a reality!
>> 
>>  
>> 
>>-- Mike
>> 
>>  
>> 
>> P.S.  This announcement was also posted at http://self-issued.info/?p=1883 
>> and as @selfissued.
>> 
>>  
>> 
>> 
>> ___
>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi George,

I‘m intrigued by the idea to encapsulate scope preparation and resource 
identification 
into the RS. This seems to be a viable pattern to implement 
transaction-oriented 
authorization.

I‘m not sure whether this justifies the implementation of UMA 2.0 in AS 
(additional 
grant types, claims interaction endpoint, endpoints for RS/AS interactions), 
RS and client. 

I think the basic idea could also be utilized by preparing a 
transaction-specific 
scope value when the client calls the RS for the first time. The client could 
then pass this value in the scope parameter as part of a standard authz code 
grant type authz request.

Does this sound reasonable?

best regards,
Torsten.

> Am 27.06.2018 um 12:13 schrieb George Fletcher :
> 
> Yes, that is the basic idea and matches the UMA flow. I think some profiling 
> of UMA is required but may be good place to start.
> 
> Thanks,
> George
> 
> --
> Identity Standards Architect
> Identity Engineering 
> Oath
> 
>> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt  
>> wrote:
>> 
>> Hi George,
>> 
>> thanks a lot for investing the time to assemble this flow description!
>> 
>> If I got it right the idea is to move the definition of the required 
>> permissions (scope) 
>> of the requested access token to the interaction between signing service and 
>> authz service
>> when the permission ticket is obtained as reaction to the attempt of the 
>> client (the insurance 
>> company) to sign a document. So the client does not need to know what scope 
>> to request.
>> It instead uses the permission ticket (minted by the RS and the AS) to 
>> request the needed 
>> permissions. 
>> 
>> Is that correct?
>> 
>> best regards,
>> Torsten.
>> 
>>> Am 24.06.2018 um 15:01 schrieb George Fletcher :
>>> 
>>> Not sure I have the flow exactly correct... here is an attempt to define a 
>>> flow based on UMA. It's a little difficult to label which flows are which 
>>> parts of the specs. Specifically I am using...
>>> 
>>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
>>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html
>>> 
>>> If you want the see the image... take the following text and load it into 
>>> https://www.websequencediagrams.com/
>>> 
>>> title Signing Sequence
>>> 
>>> participant "Browser" as B
>>> participant "Insurer" as I
>>> participant "Signer" as S
>>> participant "Bank\n(UMA AS)" as A
>>> 
>>> B->I: complete process
>>> I->S: sign doc\n(required params)
>>> S->A: permission req\n(what the signer needs)
>>> A->S: permission ticket
>>> S->I: Not authorized\n(AS + permission tckt)
>>> I->A: request RPT\n(permission tckt)
>>> A->I: need_info
>>> I-->B: redirect
>>> B->A: claims interaction endpoint
>>> A->B: user verification & consent
>>> B->A: user meets required claims
>>> A-->B: redirect
>>> B->I: user met claimns\n(permission tckt)
>>> I->A: request RPT\n(permission tckt)
>>> A->I: RPT issued
>>> I->S: sign doc\n(RPT)
>>> S->A: introspect\n(RPT)
>>> A->S: permissions\n(required params)
>>> S->I: Signed doc
>>> 
>>> 
>>> 
>>>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
>>>> Hi George,
>>>> 
>>>> how is the dynamic nature (hash) of the authorization request handled in 
>>>> your solution?
>>>> 
>>>> Note: the signing service is not provided by the insurance company but a 
>>>> third party, a sol-called trusted service provider. The insurance company 
>>>> as the client in this flow sends the request to this provider.
>>>> 
>>>> best regards,
>>>> Torsten.
>>>> 
>>>> Am 23.06.2018 um 21:07 schrieb George Fletcher :
>>>> 
>>>>> Thanks Torsten.
>>>>> 
>>>>> I think I have a solution :) Just to make sure I have the flow correct
>>>>> 
>>>>> Assumption: Using a mobile client
>>>>> 
>>>>> 1. User (using their mobile client) attempts to sign a document with the 
>>>>> insurance company
>>>>> 2. Insurance company redirects the user to their Bank asking for identity 
>>>>> proof, and signing of specific documents
>>

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi George,

thanks a lot for investing the time to assemble this flow description!

If I got it right the idea is to move the definition of the required 
permissions (scope) 
of the requested access token to the interaction between signing service and 
authz service
when the permission ticket is obtained as reaction to the attempt of the client 
(the insurance 
company) to sign a document. So the client does not need to know what scope to 
request.
It instead uses the permission ticket (minted by the RS and the AS) to request 
the needed 
permissions. 

Is that correct?

best regards,
Torsten.

> Am 24.06.2018 um 15:01 schrieb George Fletcher :
> 
> Not sure I have the flow exactly correct... here is an attempt to define a 
> flow based on UMA. It's a little difficult to label which flows are which 
> parts of the specs. Specifically I am using...
> 
> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05..html
> 
> If you want the see the image... take the following text and load it into 
> https://www.websequencediagrams.com/
> 
> title Signing Sequence
> 
> participant "Browser" as B
> participant "Insurer" as I
> participant "Signer" as S
> participant "Bank\n(UMA AS)" as A
> 
> B->I: complete process
> I->S: sign doc\n(required params)
> S->A: permission req\n(what the signer needs)
> A->S: permission ticket
> S->I: Not authorized\n(AS + permission tckt)
> I->A: request RPT\n(permission tckt)
> A->I: need_info
> I-->B: redirect
> B->A: claims interaction endpoint
> A->B: user verification & consent
> B->A: user meets required claims
> A-->B: redirect
> B->I: user met claimns\n(permission tckt)
> I->A: request RPT\n(permission tckt)
> A->I: RPT issued
> I->S: sign doc\n(RPT)
> S->A: introspect\n(RPT)
> A->S: permissions\n(required params)
> S->I: Signed doc
> 
> 
> 
>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
>> Hi George,
>> 
>> how is the dynamic nature (hash) of the authorization request handled in 
>> your solution?
>> 
>> Note: the signing service is not provided by the insurance company but a 
>> third party, a sol-called trusted service provider. The insurance company as 
>> the client in this flow sends the request to this provider.
>> 
>> best regards,
>> Torsten.
>> 
>> Am 23.06.2018 um 21:07 schrieb George Fletcher :
>> 
>>> Thanks Torsten.
>>> 
>>> I think I have a solution :) Just to make sure I have the flow correct
>>> 
>>> Assumption: Using a mobile client
>>> 
>>> 1. User (using their mobile client) attempts to sign a document with the 
>>> insurance company
>>> 2. Insurance company redirects the user to their Bank asking for identity 
>>> proof, and signing of specific documents
>>> 3. User interacts with Bank to get authorization for the specific 
>>> transaction
>>> 4. Mobile client submits request to insurance company using token that is 
>>> specific to the user, document etc.
>>> 
>>> This is effectively the UMA 2.0 flow [1]
>>> 
>>> 1. Mobile client attempts to invoke resource at the insurance company
>>> 2. Insurance company registers the request with UMA AS (the bank in this 
>>> case) and gets a permissions ticket
>>> 3. Insurance company instructs mobile client to contact the bank
>>> 4. Mobile client contacts the bank specifying the permissions ticket
>>> 5. User meets banks requirements for the specific transaction (claims 
>>> interaction)
>>> 6. Bank issues mobile client the RPT (token)
>>> 7. Mobile client invokes resource at insurance company with RPT
>>> 
>>> Note that the insurance company can specify the necessary bits that need to 
>>> be in the token when it interacts with the Bank (as the UMA AS). [There 
>>> might be some profiling required here]
>>> 
>>> I think it's worth exploring whether UMA will solve this use case.
>>> 
>>> Thanks,
>>> George
>>> 
>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html
>>> 
>>>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>>>>> 
>>>>> I would think that the scope issued to the refresh_token could represent 
>>>>> the category or class of authorizations the refresh_token should be able 
>>>>> to perform. For examp

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi George,

how is the dynamic nature (hash) of the authorization request handled in your 
solution?

Note: the signing service is not provided by the insurance company but a third 
party, a sol-called trusted service provider. The insurance company as the 
client in this flow sends the request to this provider.

best regards,
Torsten.

> Am 23.06.2018 um 21:07 schrieb George Fletcher :
> 
> Thanks Torsten.
> 
> I think I have a solution :) Just to make sure I have the flow correct...
> 
> Assumption: Using a mobile client
> 
> 1. User (using their mobile client) attempts to sign a document with the 
> insurance company
> 2. Insurance company redirects the user to their Bank asking for identity 
> proof, and signing of specific documents
> 3. User interacts with Bank to get authorization for the specific transaction
> 4. Mobile client submits request to insurance company using token that is 
> specific to the user, document etc.
> 
> This is effectively the UMA 2.0 flow [1]
> 
> 1. Mobile client attempts to invoke resource at the insurance company
> 2. Insurance company registers the request with UMA AS (the bank in this 
> case) and gets a permissions ticket
> 3. Insurance company instructs mobile client to contact the bank
> 4. Mobile client contacts the bank specifying the permissions ticket
> 5. User meets banks requirements for the specific transaction (claims 
> interaction)
> 6. Bank issues mobile client the RPT (token)
> 7. Mobile client invokes resource at insurance company with RPT
> 
> Note that the insurance company can specify the necessary bits that need to 
> be in the token when it interacts with the Bank (as the UMA AS). [There might 
> be some profiling required here]
> 
> I think it's worth exploring whether UMA will solve this use case.
> 
> Thanks,
> George
> 
> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html
> 
>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>> 
>>> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>>> 
>>> I would think that the scope issued to the refresh_token could represent 
>>> the category or class of authorizations the refresh_token should be able to 
>>> perform. For example, the kind of transactions that can be bound to access 
>>> tokens. The scope issued into the access_token could be one of the 
>>> "parameterized" ones. But maybe I'm not fully understanding the use case :)
>> Let me try to explain ;-)
>> 
>> The client is an issuance company wanting the customer to electronically 
>> sign a new contract (legally binding!). Signing in the end means to send a 
>> request containing the hash of the document to an API. The API will respond 
>> with an CM/S Object containing signature, certificate etc that the client 
>> will embedded in the contract document (typical PDF).
>> 
>> We want the user to authorize the signing request using their bank as 
>> IDP/AS. Therefore the client sends the OAuth authorization request to the 
>> AS. The actual signing request needs to be bound to client, user AND hash 
>> (document) in order to prevent fraud. Regulation (eIDAS) requires to always 
>> demonstrate the sole control of the user over the whole process. The AS 
>> therefore binds (scopes) the access token to exactly this single 
>> document/signing request. If the client wants the user to sign another 
>> document, it needs to got through the whole process again.
>> 
>> One could think about a general signing permission represented by a refresh 
>> token, but not in the high assurance level cases I‘m looking into..
>> 
>> Hope that helps,
>> Torsten.
>> 
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi Nat,

I thought the same when we started this endeavor.

What I learned is this has privacy/confidentiality implications since the AS 
learns the content of the document. For example, sending the document to a 
staging API also requires a consent of the user (given prior to the data 
transfer!) in case PII is contained in the document.

Moreover, depending on the format of the document, the AS needs different 
viewers, which increases complexity.

So the current concept (which is also standard practice in this sector) is the 
client shows the prepared and signed document before and after the signing 
process and is legally obliged to do it correctly.

The AS is responsible for providing the signing service with verified person 
data and captures the user‘s intent to sign. Both require consent.

best regards,
Torsten.

> Am 23.06.2018 um 15:13 schrieb n-sakimura :
> 
> Torsten,
> 
> For the digital signature case, I feel a bit uneasy to sign the hash that was 
> sent by the client. The signing mechanism, a bank in this case, should 
> display what is being signed to the user before the user makes a signature. 
> The staging strategy works here as well. The client sends the signed document 
> to the staging server and the bank verifies the signature and shows the 
> document to the user, where the user can view the document and when he 
> decides to sign it, the signature over the document’s hash will be made so 
> that it will result in a mutually signed document.
> 
> Best,
> 
> Nat
> 
> Nat Sakimura
> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
> 
> 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: OAuth  on behalf of Torsten Lodderstedt 
> 
> Sent: Saturday, June 23, 2018 3:43:50 AM
> To: George Fletcher
> Cc: Brian Campbell; oauth
> Subject: Re: [OAUTH-WG] Dynamic Scopes
>  
> 
> 
> > Am 22.06.2018 um 23:08 schrieb George Fletcher :
> > 
> > I would think that the scope issued to the refresh_token could represent 
> > the category or class of authorizations the refresh_token should be able to 
> > perform. For example, the kind of transactions that can be bound to access 
> > tokens. The scope issued into the access_token could be one of the 
> > "parameterized" ones. But maybe I'm not fully understanding the use case :)
> 
> Let me try to explain ;-)
> 
> The client is an issuance company wanting the customer to electronically sign 
> a new contract (legally binding!). Signing in the end means to send a request 
> containing the hash of the document to an API. The API will respond with an 
> CM/S Object containing signature, certificate etc that the client will 
> embedded in the contract document (typical PDF).
> 
> We want the user to authorize the signing request using their bank as 
> IDP/AS.. Therefore the client sends the OAuth authorization request to the 
> AS. The actual signing request needs to be bound to client, user AND hash 
> (document) in order to prevent fraud. Regulation (eIDAS) requires to always 
> demonstrate the sole control of the user over the whole process. The AS 
> therefore binds (scopes) the access token to exactly this single 
> document/signing request. If the client wants the user to sign another 
> document, it needs to got through the whole process again.
> 
> One could think about a general signing permission represented by a refresh 
> token, but not in the high assurance level cases I‘m looking into.
> 
> Hope that helps,
> Torsten.
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

> Am 22.06.2018 um 23:08 schrieb George Fletcher :
> 
> I would think that the scope issued to the refresh_token could represent the 
> category or class of authorizations the refresh_token should be able to 
> perform. For example, the kind of transactions that can be bound to access 
> tokens. The scope issued into the access_token could be one of the 
> "parameterized" ones. But maybe I'm not fully understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sign a 
new contract (legally binding!). Signing in the end means to send a request 
containing the hash of the document to an API. The API will respond with an 
CM/S Object containing signature, certificate etc that the client will embedded 
in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS.. 
Therefore the client sends the OAuth authorization request to the AS. The 
actual signing request needs to be bound to client, user AND hash (document) in 
order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the 
sole control of the user over the whole process. The AS therefore binds 
(scopes) the access token to exactly this single document/signing request. If 
the client wants the user to sign another document, it needs to got through the 
whole process again.

One could think about a general signing permission represented by a refresh 
token, but not in the high assurance level cases I‘m looking into.

Hope that helps,
Torsten.




smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi George, 

> Am 22.06.2018 um 19:51 schrieb George Fletcher :
> 
> I like the concept of parameterized scopes but I'm not sure they should be 
> used for per-transaction use cases. It seems like the use cases presented are 
> about operating on parameters specific to the transaction. Why are these part 
> of the authorization flow?

The access token is good for a certain transaction only. In case of a 
electronic signature, the access token is bound to a certain document or a set 
of documents.

> 
> Is the goal to bind an access token to a particular transaction? If this is 
> the case, would it not be better to either extend the refresh_token flow or 
> may better yet, create a new grant_type that takes the refresh_token and 
> additional "binding" parameters and then have that return the "bound" access 
> token to be used for the transaction.

What would be the scope of such a refresh token? 

> 
> Maybe this is similar to what Nat is describing with the staging API?

The staging API represents the data of a certain transaction in a resource, 
which allows to parametrize the scope just with the identifier of that 
resource. So the transaction data can be transmitted in a robust fashion. 

best regards,
Torsten. 

> 
> Thanks,
> George
> 
> On 6/20/18 5:58 PM, Brian Campbell wrote:
>> In my own personal and humble opinion, Torsten, what you describe as "(1) 
>> Parameter is part of the scope value" is the most natural approach and works 
>> without needing changes to, or going outside of, RFC6749 The OAuth 2.0 
>> Authorization Framework. There may be AS implementations that have made 
>> assumption about scope values being static (I know of at least one!) but 
>> that's an implementation/feature issue, which can change, and not a spec 
>> issue.
>> 
>> The OIDC "claims" parameter is already a bit of a hairy beast and I think 
>> using it and the ID Token to convey more dynamic access/authorization is 
>> blurring the line between authorization and authentication a bit much. Also, 
>> as others have pointed out, OIDC isn't always in play - particularly for 
>> regular old authorization cases.  
>> 
>> An additional query parameter might be simple for a one-off case but it's 
>> nonstandard and not very repeatable. 
>> 
>> 
>> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt 
>>  wrote:
>> Hi all,
>> 
>> I have been working lately on use cases where OAuth is used to authorize 
>> transactions in the financial sector and electronic signing. What I learned 
>> is there is always the need to pass resource ids (e.g. account numbers) or 
>> transaction-specific values (e.g. amount or hash to be signed) to the OAuth 
>> authorization process to further qualify the scope of the requested access 
>> token. 
>> 
>> It is obvious a static scope value, such as „payment“or „sign“, won’t do the 
>> job. For example in case of electronic signing, one must bind the 
>> authorization/access token to a particular document, typically represented 
>> by its hash.
>> 
>> I would like to get your feedback on what you consider a good practice to 
>> cope with that challenge. As a starting point for a discussion, I have 
>> assembled a list of patterns I have seen in the wild (feel free to extend). 
>> 
>> (1) Parameter is part of the scope value, e.g. „sign:“ or 
>> "payments:" - I think this is an obvious way to 
>> represent such parameters in OAuth, as it extends the scope parameter, which 
>> is intended to represent the requested scope of an access token. I used this 
>> pattern in the OAuth SCA mode in Berlin Group's PSD API. 
>> 
>> (2) One could also use additional query parameter to add further details re 
>> the requested authorization, e.g. 
>> 
>> GET /authorize?
>> .
>> =sign
>> .
>> _to_be_signed=
>> 
>> It seems to be robust (easier to implement?) but means the scope only 
>> represents the static part of the action. The AS needs to look into a 
>> further parameter to fully understand the requested authorization. 
>> 
>> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to 
>> carry additional data. 
>> 
>> Example:  
>> 
>> "claims": {
>> "id_token": {
>> "acr": {
>> "essential": true,
>> "value": "..."
>>   },
>> "hash_to_be_signed": {
>> "essential": true,
>> "value": ""
>

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi Nat,

> Am 21.06.2018 um 10:35 schrieb Nat Sakimura :
> 
> It depends on the use case but if you are talking about payment etc., putting 
> the transaction details in the scope and sending it over the regular RFC6749 
> redirect to the authorization server is inherently a bad idea, as it is not 
> protected. 

Good point. One could carry the scope parameter as part of a signed request 
object to cope with that issue. What do you think about that?

> 
> My preference by far is to set up a staging endpoint and push the transaction 
> intent into there. Then, do the authorization on that staged transaction. 
> Once that's done. I am OK with putting the reference to the staged 
> transaction in the scope parameter. 
> 
> The beauty of the "staging" strategy is that: 
> 
> 1) You can push pretty big payload to the staging endpoint as it is a server 
> to server thing; 
> 2) You can do the "auth" and then later "capture" after shipping the product 
> strategy using the access token the client has obtained; 
> 3) The content of the transaction is not exposed via URL nor referrers. 

I agree. That’s really powerful. But one should also admit the client needs to 
prepare and send two more requests. In OB UK the client first obtains an access 
token using the client credentials grant and then creates the payment/account 
information resource. 

best regards,
Torsten. 

> 
> Best, 
> 
> Nat
> 
> 
> 
> On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell 
>  wrote:
> In my own personal and humble opinion, Torsten, what you describe as "(1) 
> Parameter is part of the scope value" is the most natural approach and works 
> without needing changes to, or going outside of, RFC6749 The OAuth 2.0 
> Authorization Framework. There may be AS implementations that have made 
> assumption about scope values being static (I know of at least one!) but 
> that's an implementation/feature issue, which can change, and not a spec 
> issue.
> 
> The OIDC "claims" parameter is already a bit of a hairy beast and I think 
> using it and the ID Token to convey more dynamic access/authorization is 
> blurring the line between authorization and authentication a bit much. Also, 
> as others have pointed out, OIDC isn't always in play - particularly for 
> regular old authorization cases.  
> 
> An additional query parameter might be simple for a one-off case but it's 
> nonstandard and not very repeatable. 
> 
> 
> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt 
>  wrote:
> Hi all,
> 
> I have been working lately on use cases where OAuth is used to authorize 
> transactions in the financial sector and electronic signing. What I learned 
> is there is always the need to pass resource ids (e.g. account numbers) or 
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth 
> authorization process to further qualify the scope of the requested access 
> token. 
> 
> It is obvious a static scope value, such as „payment“or „sign“, won’t do the 
> job. For example in case of electronic signing, one must bind the 
> authorization/access token to a particular document, typically represented by 
> its hash.
> 
> I would like to get your feedback on what you consider a good practice to 
> cope with that challenge. As a starting point for a discussion, I have 
> assembled a list of patterns I have seen in the wild (feel free to extend). 
> 
> (1) Parameter is part of the scope value, e.g. „sign:“ or 
> "payments:" - I think this is an obvious way to 
> represent such parameters in OAuth, as it extends the scope parameter, which 
> is intended to represent the requested scope of an access token. I used this 
> pattern in the OAuth SCA mode in Berlin Group's PSD API. 
> 
> (2) One could also use additional query parameter to add further details re 
> the requested authorization, e.g. 
> 
> GET /authorize?
> .
> =sign
> .
> 
> _to_be_signed=
> 
> It seems to be robust (easier to implement?) but means the scope only 
> represents the static part of the action. The AS needs to look into a further 
> parameter to fully understand the requested authorization. 
> 
> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry 
> additional data. 
> 
> Example:  
> 
> "claims": {
> "id_token": {
> "acr": {
> "essential": true,
> "value": "..."
>   },
> "hash_to_be_signed": {
> "essential": true,
> "value": ""
> }
> },
> "userinfo": {
> &quo

Re: [OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi Jacob,

thanks for your thoughts on dynamic scopes. 

> Am 19.06.2018 um 08:16 schrieb Jacob Ideskog :
> 
> For OpenID I still think the signed claims parameters make a more flexible 
> approach, but OpenID isn't always in play.

Why do you think it is more flexible? 

kind regards,
Torsten. 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi all,

I have been working lately on use cases where OAuth is used to authorize 
transactions in the financial sector and electronic signing. What I learned is 
there is always the need to pass resource ids (e.g. account numbers) or 
transaction-specific values (e.g. amount or hash to be signed) to the OAuth 
authorization process to further qualify the scope of the requested access 
token. 

It is obvious a static scope value, such as „payment“or „sign“, won’t do the 
job. For example in case of electronic signing, one must bind the 
authorization/access token to a particular document, typically represented by 
its hash.

I would like to get your feedback on what you consider a good practice to cope 
with that challenge. As a starting point for a discussion, I have assembled a 
list of patterns I have seen in the wild (feel free to extend). 

(1) Parameter is part of the scope value, e.g. „sign:“ or 
"payments:" - I think this is an obvious way to represent 
such parameters in OAuth, as it extends the scope parameter, which is intended 
to represent the requested scope of an access token. I used this pattern in the 
OAuth SCA mode in Berlin Group's PSD API. 

(2) One could also use additional query parameter to add further details re the 
requested authorization, e.g. 

GET /authorize?

=sign

_to_be_signed=

It seems to be robust (easier to implement?) but means the scope only 
represents the static part of the action. The AS needs to look into a further 
parameter to fully understand the requested authorization. 

(3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry 
additional data. 

Example:  

"claims": {
"id_token": {
"acr": {
"essential": true,
"value": "..."
  },
"hash_to_be_signed": {
"essential": true,
"value": ""
}
},
"userinfo": {
"hash_to_be_signed": {
"essential": true,
"value": ""
}
}
  }

I‘m looking forward for your feedback. Please also indicated whether you think 
we should flush out a BCP on that topic. 

kind regards,
Torsten.

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-security-topics

[Torsten Lodderstedt]

SON Object Signing and Encryption (JOSE)",  
RFC 8037, DOI 10.17487/RFC8037, January 2017,   
 <https://www.rfc-editor.org/info/rfc8037>.

related to your text proposal - not adopted for the moment


Section 7.2. Informative References
FROM
draft-ietf-oauth-jwsreq-15 (work in progress), July 2017.   
TO
draft-ietf-oauth-jwsreq-16 (work in progress), April 2018.
thanks for pointing this out. My local environment somehow fetched 
outdated data. It's been corrected now.


FROM
mtls-07 (work in progress), January 2018.
TO
mtls-08 (work in progress), May 2018.

FROM
tokbind-https-12 (work in progress), January 2018.
TO
tokbind-https-14 (work in progress), May 2018.

Does that help?

yes!

best regards,
Torsten.


Thanks,

Doug

-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, May 20, 2018 4:30 AM
To: McDorman, Doug 
Cc: draft-ietf-oauth-security-top...@ietf.org
Subject: Re: draft-ietf-oauth-security-topics

Hi Doug,

thanks for your feedback. I changed the names to comply to RFC 2606.

Can you please add all proposals to the body of your posting (including 
section/page references)? Otherwise, it’s nearly impossible to discuss 
proposals on the list.

best regards,
Torsten.


Am 08.05.2018 um 08:48 schrieb McDorman, Doug :

Hi working group, I made some edits to the current draft of this document. 
Edited version attached.
  
The changes probably are not in the exact desired format, I have not edited an RFC before and I am not familiar with the tools and process.
  
Summary:

• I added a section 3.10.  Cryptographic Agility
• The domain evil.com is used but that is a real URL so I changed 
references to be evil.test.com, According to  
https://tools.ietf.org/html/rfc2606  test.com should be safe to use in 
documentation.
• There was one wrong URL of https://evil.example.com/cb, which should 
have been https://client.evil.com/cbalthough I changed to 
https://client.evil.test.com/cb to be consistent with the other changes from 
evil.com to test.com
• Updated some of the references to newer versions
• A few other minor spacing issues
  
Let me know if I can clarify anything or provide additional assistance.
  
Thanks,
  
Doug
  
Doug McDorman

Principal Architect, Security
  


douglas.mcdor...@t-mobile.com
www.t-mobile.com
  



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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

[Torsten Lodderstedt]

Hi Johan,

thanks for your proposal. I’m not sure whether it should go to 3.7.1.4. The 
reason audience restriction turns up as a subsection of 3.7 is our document is 
organized by attacks instead of security controls. I could image to add a 
section on audience/action restriction as sub section of 2.

What is the mean reason for restricting access tokens to certain actions? Is it 
about least privileges? Is it to limit the impact of a token leakage/replay? ...

best regards,
Torsten.  

> Am 07.04.2018 um 19:11 schrieb Johan Peeters :
> 
> Thanks for doing this great work, Torsten. As discussed in a private
> email conversation, I think an access token should not only be
> explicit about which resource server is the intended consumer
> (audience), but also which actions are permitted on the targeted
> resources:
> 
> =3.7.1.4. Action Restricted Access Tokens=
> 
>   An action restriction restricts the action a
>   particular access token can be used for.  The authorization server
>   associates the access token with a certain action and every
>   resource server is obliged to verify for every request, whether the
>   access token sent with that request was meant to be used for that
>   particular action.  If not, the resource server must refuse
>   to serve the respective request.  Action
>   restrictions limit the impact of a token leakage and prevent a
> malicious client to use the token for unintended actions.
> 
>   The action attribute in  can be expressed as the HTTP verb used to
> make the request.
> 
>   The client needs to tell the authorization server, for which actions it
>   will use the access token it is requesting.  It should encode
>   the information in the scope value.
> 
>   Action restrictions are essential both to enforce scope
> restrictions as established through user dialog and policy decisions
> by the authorization server.
> 
> ==
> 
> Yo
> -- 
> Johan Peeters
> https://www.johanpeeters.com



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt

[Torsten Lodderstedt]

Hi George, 

> Am 01.06.2018 um 17:41 schrieb George Fletcher :
> 
> What is the expectation if the RS requests a signed JWT response but the AS 
> doesn't support it? Should getting a signed response require both? (meaning 
> the Accept header and an AS config that that RP wants it)? That may be the 
> safest from a backward compatibility perspective.

we assume the RS is set up with the AS in advance, so the RS should know 
whether the AS supports signing. 

> 
> I have some concerns around relying on 'iss' and 'aud' to prevent abuse

It’s iss + aud + all replay prevention means you can think of (including token 
binding).

> and wonder if a JWT Header claim describing the context of the JWT might be 
> better. 

Any suggestions (cty)? I’m not sure abuse can be prevented that way since 
developers need to consider this header claim.

best regards,
Torsten. 

> 
> Thanks,
> George
> 
> On 5/28/18 12:58 PM, Torsten Lodderstedt wrote:
>> Hi all, 
>> 
>> I just published a new revision of the JWT Introspection response draft. 
>> Based on the feedback in London, the draft entirely focuses on use cases 
>> where the RS requires stronger assurance that the respective AS issued the 
>> token, including cases where the AS assumes liability for the token’s 
>> content. 
>> 
>> We incorporated the following changes:
>>  • fixed typos in client meta data field names (thanks Petteri!)
>>  • added OAuth Server Metadata parameters to publish algorithms 
>> supported for signing and encrypting the introspection response
>>  • added registration of new parameters for OAuth Server Metadata and 
>> Client Registration
>>  • added explicit request for JWT introspection response
>>  • made iss and aud claims mandatory in introspection response (thanks 
>> Neil!)
>>  • Stylistic and clarifying edits, updates references
>> 
>> Thanks to all reviewers!
>> 
>> Vladimir and I are on the fence whether the Introspection Response format 
>> should be determined by the AS based on its policy and/or RS-related 
>> registration metadata or whether the RS should explicitly request a JWT 
>> response by including an Accept header „application/jwt“ in the respective 
>> request. 
>> 
>> What do you think?
>> 
>> kind regards,
>> Torsten.
>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: internet-dra...@ietf.org
>>> Betreff: New Version Notification for 
>>> draft-lodderstedt-oauth-jwt-introspection-response-01.txt
>>> Datum: 28. Mai 2018 um 18:48:02 MESZ
>>> An: "Vladimir Dzhuvinov" , "Torsten Lodderstedt" 
>>> 
>>> 
>>> 
>>> A new version of I-D, 
>>> draft-lodderstedt-oauth-jwt-introspection-response-01.txt
>>> has been successfully submitted by Torsten Lodderstedt and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-lodderstedt-oauth-jwt-introspection-response
>>> Revision:   01
>>> Title:  JWT Response for OAuth Token Introspection
>>> Document date:  2018-05-28
>>> Group:  Individual Submission
>>> Pages:  10
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-01.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
>>> Diff:   
>>> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-jwt-introspection-response-01
>>> 
>>> Abstract:
>>>   This draft proposes an additional JSON Web Token (JWT) based response
>>>   for OAuth 2.0 Token Introspection.
>>> 
>>> 
>>> 
>>> 
>>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Torsten Lodderstedt]

Hi Neil,

> Am 25.05.2018 um 12:49 schrieb Neil Madden <neil.mad...@forgerock.com>:
> 
> Hi Torsten,
> 
>> On 25 May 2018, at 10:35, Torsten Lodderstedt <tors...@lodderstedt.net> 
>> wrote:
>> 
>> Hi Neil,
>> 
>>> Am 28.03.2018 um 17:41 schrieb Neil Madden <neil.mad...@forgerock.com>:
>>> 
>>> I like this draft, but I want to clarify if it is intended that the 
>>> response JWT could be interpreted as an OpenID Connect ID Token? As the set 
>>> of claims can overlap (in particular, all required ID token claims are 
>>> valid token introspection response fields) and it seems highly likely that 
>>> an AS will use the same keys for signing both (and it definitely will when 
>>> the client_secret is used for signing), the signed response JWT could well 
>>> be indistinguishable from an ID token (for the resource owner) with some 
>>> additional claims.
>> 
>> Conceptually, the introspection response, an ID Token and even structured 
>> access tokens are quite the same if they carry user identifiers or claims. 
>> They identify the respective user account towards RP or RS and provide 
>> additional attributes, which, for example, can be used to meet access 
>> control decisions. And if JWT is the representation, they are also 
>> syntactically (nearly) equivalent. The main difference I see that an ID 
>> Token may contain a nonce, which is not required in access tokens.
> 
> Are they the same? An ID token authenticates (claims about) a user to the RP.

The same definition holds true for access tokens towards RSs.

> I don’t think that is the intended interpretation of a token introspection 
> response, and it’s not the purpose of an access token. My point is that as 
> specified they can be syntactically identical and yet intended for different 
> purposes.

The difference is just the role the party is taking in the overall protocol 
flow. In my experience, contents of access tokens and contents of ID tokens 
tend to be rather similar, at least in the consumer identity space. 

> 
>> 
>>> 
>>> If this is not the case, then maybe consider adding a “crit”: [“scope”] 
>>> claim to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11) 
>>> to indicate that the scope claim must be understood.
>> 
>> What do you want to achieve/prevent?
> 
> The sorts of issues discussed in 
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-2.7
> 
> As I said in a follow-up email, “crit” does not actually work here as it only 
> applies to headers. If we wanted to distinguish them, we could use explicit 
> typing as recommended in the BCP: 
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-3.11 and have 
> a type of “introspection+jwt” or something like that (with an appropriate 
> media type registration).

The text also states "Note that this is a specific type of substitution 
attack.“ and I fully agree with this assessment. In my opinion, the consequence 
is that all the countermeasures available for token substitution can and must 
be used to detect such misuse. In the particular case of an an attacker wanting 
to use a token introspection response JWT as ID token in a different flow, all 
security checks defined by OpenId Connect 
(http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) must 
be performed. This means the RP must, for example, validate issuer, audience 
and nonce. This should be sufficient to prevent any kind of abuse.

> 
>> 
>>> 
>>> I can think of one potential use-case (I’ll let you decide the merits of 
>>> it) where it might actually be useful to explicitly allow the response to 
>>> be an ID Token. Consider an application (RS) that uses a traditional 
>>> authorization model: it authenticates a user, sets a cookie, and then based 
>>> on who that user is makes dynamic access control decisions to see what they 
>>> are allowed to do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this 
>>> app to modern standards would be to replace the home-spun authentication 
>>> system with OIDC, but leave the rest in place. Now the system uses OIDC to 
>>> authenticate the user, sets the ID token as the cookie, and then still 
>>> applies the same access control decisions that it always has done.
>>> 
>>> Now imagine that a new requirement comes in to support OAuth 2.0 access 
>>> tokens to allow delegation to third-party apps. A really simple way to 
>>> achieve that would be to put a filter/reverse proxy in front of the RS that 
>>> extracts access tokens coming in, performs signed JWT token

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Torsten Lodderstedt]

HI Petteri,

thanks for your feedback. I incorporated it in the upcoming revision. 

kind regards,
Torsten. 

> Am 26.03.2018 um 11:02 schrieb Petteri Stenius 
> <petteri.sten...@ubisecure.com>:
> 
> Hi all,
>  
> I want to show my support for this proposal
>  
>  
> I believe the two use cases presented at the IETF meeting [1] are important:
>  
> 1. implementing application level end-to-end integrity protection of the 
> introspection response
> 2. simple conversion of by-reference access tokens into by-value JWT encoded 
> tokens
>  
>  
> This proposal adds three fields to the client metadata. I think there are two 
> issues that should be addressed:
>  
> 1. Remove double "response" from field names. Replace 
> "introspection_response_signed_response_alg" with 
> "introspection_signed_response_alg". Also address two other fields
> 2. Add corresponding fields to provider metadata. For client metadata field 
> "introspection_signed_response_alg" there should exist 
> "introspection_signing_alg_values_supported" in provider metadata. The two 
> other fields need corresponding fields as well.
>  
>  
> Relationship with OpenID Connect
>  
> In OpenID Connect the userinfo endpoint is very similar to introspection 
> endpoint of OAuth. Userinfo supports JWT signing and encryption. Adding JWT 
> signing and encryption to introspection endpoint fills the gap between the 
> two specifications.
>  
>  
> Best regards,
> Petteri Stenius
>  
> [1] 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessb-jwt-introspection-response-01
>  
>  
>  
> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Torsten Lodderstedt
> Sent: sunnuntai 18. maaliskuuta 2018 21.33
> To: oauth <oauth@ietf.org>
> Subject: [OAUTH-WG] Fwd: New Version Notification for 
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>  
> Hi all,
>  
> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It 
> proposes a JWT-based response type for Token Introspection. The objective is 
> to provide resource servers with signed tokens in case they need 
> cryptographic evidence that the AS created the token (e.g. for liability). 
>  
> I will present the new draft in the session on Wednesday.
>  
> kind regards,
> Torsten. 
> 
> 
> Anfang der weitergeleiteten Nachricht:
>  
> Von: internet-dra...@ietf.org
> Betreff: New Version Notification for 
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> Datum: 18. März 2018 um 20:19:37 MEZ
> An: "Vladimir Dzhuvinov" <vladi...@connect2id.com>, "Torsten Lodderstedt" 
> <tors...@lodderstedt.net>
>  
> 
> A new version of I-D, 
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name:   
> draft-lodderstedt-oauth-jwt-introspection-response
> Revision: 00
> Title:   JWT Response for OAuth Token Introspection
> Document date:  2018-03-15
> Group:  Individual Submission
> Pages:   5
> URL:
> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
> Htmlized:   
> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
> 
> 
> Abstract:
>   This draft proposes an additional JSON Web Token (JWT) based response
>   for OAuth 2.0 Token Introspection.
> 
> 
> 
> 
> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Torsten Lodderstedt]

Hi Neil,

> Am 28.03.2018 um 17:41 schrieb Neil Madden <neil.mad...@forgerock.com>:
> 
> I like this draft, but I want to clarify if it is intended that the response 
> JWT could be interpreted as an OpenID Connect ID Token? As the set of claims 
> can overlap (in particular, all required ID token claims are valid token 
> introspection response fields) and it seems highly likely that an AS will use 
> the same keys for signing both (and it definitely will when the client_secret 
> is used for signing), the signed response JWT could well be indistinguishable 
> from an ID token (for the resource owner) with some additional claims.

Conceptually, the introspection response, an ID Token and even structured 
access tokens are quite the same if they carry user identifiers or claims. They 
identify the respective user account towards RP or RS and provide additional 
attributes, which, for example, can be used to meet access control decisions. 
And if JWT is the representation, they are also syntactically (nearly) 
equivalent. The main difference I see that an ID Token may contain a nonce, 
which is not required in access tokens. 

> 
> If this is not the case, then maybe consider adding a “crit”: [“scope”] claim 
> to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11) to 
> indicate that the scope claim must be understood.

What do you want to achieve/prevent? 

> 
> I can think of one potential use-case (I’ll let you decide the merits of it) 
> where it might actually be useful to explicitly allow the response to be an 
> ID Token. Consider an application (RS) that uses a traditional authorization 
> model: it authenticates a user, sets a cookie, and then based on who that 
> user is makes dynamic access control decisions to see what they are allowed 
> to do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this app to modern 
> standards would be to replace the home-spun authentication system with OIDC, 
> but leave the rest in place. Now the system uses OIDC to authenticate the 
> user, sets the ID token as the cookie, and then still applies the same access 
> control decisions that it always has done.
> 
> Now imagine that a new requirement comes in to support OAuth 2.0 access 
> tokens to allow delegation to third-party apps. A really simple way to 
> achieve that would be to put a filter/reverse proxy in front of the RS that 
> extracts access tokens coming in, performs signed JWT token introspection 
> against the AS to validate the token and then checks the the scopes are 
> appropriate for the request. It can then simply replace the access token in 
> the original request with the signed token introspection response (as ID 
> token) and forward it on to the original RS server. As the introspection 
> response is a valid ID token for the resource owner, the RS will then apply 
> all its normal access control checks to ensure that the resource owner 
> actually has the permissions that they have delegated to the client.
> 
> I think potentially that is quite an interesting application of this draft, 
> but I don’t think it was intended! I think probably a decision should be made 
> as to whether that kind of usage should be allowed and explicitly adjust the 
> draft to either allow or deny it. If it is allowed, then possibly there 
> should be a way for the caller to hint that they want the response to be a 
> valid ID token.

I don’t currently see a way the introspection response could be abused as ID 
Token other than the recipient of the response (or an attacker able to obtain 
the response object) sets up a fake IDP and provides the response as an ID 
token to a RP. The RP should be able to detect this (as other ways to replay ID 
tokens) by utilizing the nonce.

kind regards,
Torsten.  

> 
> Kind regards,
> 
> Neil
> 
>> On 18 Mar 2018, at 19:33, Torsten Lodderstedt <tors...@lodderstedt.net> 
>> wrote:
>> 
>> Hi all,
>> 
>> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It 
>> proposes a JWT-based response type for Token Introspection. The objective is 
>> to provide resource servers with signed tokens in case they need 
>> cryptographic evidence that the AS created the token (e.g. for liability). 
>> 
>> I will present the new draft in the session on Wednesday.
>> 
>> kind regards,
>> Torsten. 
>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: internet-dra...@ietf.org
>>> Betreff: New Version Notification for 
>>> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>>> Datum: 18. März 2018 um 20:19:37 MEZ
>>> An: "Vladimir Dzhuvinov" <vladi...@connect2id.com>, "Torsten Lodderstedt" 
>>> <t

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-06.txt

[Torsten Lodderstedt]

Hi all,

the new revision contains the following changes: 
• reworked section 3.8.1
• incorporated Phil Hunt's feedback
• reworked section on mix-up
• extended section on code leakage via referrer header to also cover 
state leakage
• added Daniel Fett as author
• replaced text intended to inform WG discussion by recommendations to 
implementors
• modified example URLs to conform to RFC 2606

Please join me in welcoming Daniel Fett (one of the researches who discovered 
the mix up attack) as another co-author of the draft!

best regards,
Torsten. 

> Am 20.05.2018 um 13:38 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>    Authors     : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>  Daniel Fett
>   Filename: draft-ietf-oauth-security-topics-06.txt
>   Pages   : 31
>   Date: 2018-05-20
> 
> Abstract:
>   This document describes best current security practices for OAuth
>   2.0.  It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and covers new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

+1

> Am 24.04.2018 um 05:33 schrieb Nat Sakimura :
> 
> +1
> 
> On Thu, Apr 19, 2018 at 3:28 AM Richard Backman, Annabelle 
> > wrote:
> I support adoption of OAuth 2.0 Incremental Authorization as a WG document.
> 
>  
> 
> -- 
> 
> Annabelle Richard Backman
> 
> Amazon – Identity Services
> 
>  
> 
> From: OAuth > on behalf of Brian Campbell 
> >
> Date: Wednesday, April 18, 2018 at 8:23 AM
> To: Rifaat Shekh-Yusef >
> Cc: oauth >
> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization
> 
>  
> 
> I support adoption of OAuth 2.0 Incremental Authorization as a WG document. <>
>  
> 
> On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-Yusef  <>> wrote:
> 
> All,
> 
>  
> 
> We would like to get a confirmation on the mailing list for the adoption of 
> the OAuth 2.0 Incremental Authorization as a WG document
> 
> https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ <>
>  
> 
> Please, let us know if you support or object to the adoption of this document.
> 
>  
> 
> Regards,
> 
>  Rifaat & Hannes
> 
>  
> 
> 
> ___
> 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.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org <>
> https://www.ietf.org/mailman/listinfo/oauth <>
> -- 
> Nat Sakimura
> 
> Chairman of the Board, OpenID Foundation
> 
> ___
> 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] scp claim in draft-ietf-oauth-token-exchange-12

[Torsten Lodderstedt]

+1 - It will makes thinks much simpler.

> Am 19.04.2018 um 00:58 schrieb Mike Jones <michael.jo...@microsoft.com>:
> 
> I’m OK with this change, given it makes the OAuth suite of specs more 
> self-consistent.
>  
>-- Mike
>  
> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell
> Sent: Wednesday, April 18, 2018 8:17 AM
> To: Torsten Lodderstedt <tors...@lodderstedt.net>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12
>  
> The draft-ietf-oauth-token-exchange document makes use of scope and at some 
> point in that work it came to light that, despite the concept of scope being 
> used lots of places elsewhere, there was no officially registered JWT claim 
> for scope. As a result, we (the WG) decided to have 
> draft-ietf-oauth-token-exchange define and register a JWT claim for scope. 
> It's kind of an awkward place for it really but that's how it came to be 
> there.
> 
> When I added it to the draft, I opted for the semi-convention of JWT using 
> three letter short claim names.. And decided to use a JSON array to convey 
> multiple values rather than space delimiting. It seemed like a good idea at 
> the time - more consistent with other JWT claim names and cleaner to use the 
> facilities of JSON rather than a delimited string. That was the thinking at 
> the time anyway and, as I recall, I asked the WG about doing it that way at 
> one of the meetings and there was general, if somewhat absent, nodding in the 
> room.
> 
> Looking at this again in the context of the question from Torsten and his 
> developers, I think using a different name and syntax for the JWT claim vs.. 
> the Introspection response member/parameter/claim is probably a mistake.  
> While RFC 7662 Introspection response parameters aren't exactly the same as 
> JWT claims, they are similar in many respects. So giving consistent treatment 
> across them to something like scope is
> 
> Therefore I propose that the JWT claim for representing scope in 
> draft-ietf-oauth-token-exchange be changed to be consistent with the 
> treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That 
> effectively means changing the name from "scp" to "scope" and the value from 
> a JSON array to a string delimited by spaces.
> 
> I realize it's late in the process to make this change but believe doing so 
> will significantly reduce confusion and issues in the long run. 
> 
>  
>  
> 
>  
>  
> On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt 
> <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
> Hi all,
> 
> I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ 
> to carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the 
> same purpose. As far as I understand the text, the intension is to represent 
> a list of RFC6749 scopes. Is this correct? What’s the rationale behind?
> 
> Different claim names for representing scope values confuse people. I 
> realized that when one of our developers pointed out that difference 
> recently. 
> 
> best regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <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.



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05

[Torsten Lodderstedt]

Hi Phil, 

thanks for reviewing it. We incorporated the respective changes in the upcoming 
-06. 

best regards,
Torsten. 

> Am 22.03.2018 um 10:52 schrieb Phil Hunt :
> 
> Torsten,
> 
> Great document!
> 
> Some minor nits and comments:
> 
> Abstract - double period after first sentence.
> 
>> It updates and extends the OAuth 2.0 Security Threat Model to
>>incorporate practical experiences gathered since OAuth 2.0 was
>>published and cover new threats relevant due to the broader
>>application of OAuth 2.0.
> 
> When I first read, it sounds like this is a replacement for the threat model 
> or at least could be read that way. I think you mean readers still need to 
> read 6819. How about...
> 
> "This specification uses the OAuth 2.0 Security Threat Model and supplements 
> it to incorporate practical experiences gathered"...
> 
> Section 1.
> 
> The paragraph starting “OAuth initially assumed a static…” appears to 
> continue the previous bullet point.  Should the paragraph be indented?
> 
> Last paragraph 3.1.1
>> This kind of injections is covered in
>>Section Code Injection.
> 
> Should this say Section 3.5?
> 
> Section 3.1.5
> This paragraph seems unfinished...
>> 
>>  Question: Does redirect uri validation solve any problem for
>>   native apps?  Effective against impersonation when used in
>>   conjunction with claimed HTTPS redirect URIs only.
>>   For Windows token broker exact redirect URI matching is important
>>   as the redirect URI encodes the app identity.  For custom scheme
>>   redirects there is a question however it is probably a useful part
>>   of defense in depth.
> 
> Section 3.4
>> AS returns client_id and its iss in the response.  Client compares
>>   this data to AS it believed it sent the user agent to.
> “client_id” and “iss” attributes do not appear to have any marking ( style=“verb”>) in multiple locations in the document.
> 
> Section 3.5
>> How does an attack look like?
> How about:
> "An attack looks like:”
> 
> Writing style of the following comment seems like an editors note rather than 
> a comment for the reader.  Rephrase?
> 
>>But this approach conflicts with the idea to enforce exact redirect
>>URI matching at the authorization endpoint.  Moreover, it has been
>>observed that providers very often ignore the redirect_uri check
>>requirement at this stage, maybe, because it doesn't seem to be
>>security-critical from reading the spec.
> 
> Is this appropriate for a BCP (seems like a WG discussion item)?
>>The authors therefore propose to the working group to drop this
>>feature in favor of more effective and (hopefully) simpler approaches
>>to code injection prevention as described in the following section.
> 
> Section 3.5.1
> 
> This seems a bit tentatively worded…
>>PKCE seem to be the most obvious solution for OAuth clients as it
>>available and effectively used today for similar purposes for OAuth
>>native apps whereas "nonce" is appropriate for OpenId Connect
>>clients.
> 
> Formatting problem (missing line between paragraphs)?
>>Note on pre-warmed secrets: An attacker can circumvent the
>>countermeasures described above if he is able to create or capture
>>the respective secret or code_challenge on a device under his
>>control, which is then used in the victim's authorization request.
>>Exact redirect URI matching of authorization requests can prevent the
>>attacker from using the pre-warmed secret in the faked authorization
>>transaction on the victim's device.
>>Unfortunately it does not work for all kinds of OAuth clients.  It is
>>effective for web and JS apps and for native apps with claimed URLs.
>>Attacks on native apps using custom schemes or redirect URIs on
>>localhost cannot be prevented this way, except if the AS enforces
>>one-time use for PKCE verifier or Nonce values.
> 
> 
> Phil
> 
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com phil.h...@oracle.com 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

[Torsten Lodderstedt]

Hi all,

I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ to 
carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the same 
purpose. As far as I understand the text, the intension is to represent a list 
of RFC6749 scopes. Is this correct? What’s the rationale behind?

Different claim names for representing scope values confuse people. I realized 
that when one of our developers pointed out that difference recently. 

best regards,
Torsten.

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

[Torsten Lodderstedt]

Hi all,

thanks for your feedback. Here is my text proposal for section 3.8.1. 

——

Attackers could try to utilize a user's trust in the authorization
   server (and its URL in particular) for performing phishing attacks. 

RFC 6749 already prevents open redirects by stating the AS
MUST NOT automatically redirect the user agent in case 
of an invalid combination of client_id and redirect_uri.  

However, as described in [I-D.ietf-oauth-closing-redirectors], an
attacker could also utilize a correctly registered redirect URI to 
perform phishing attacks. It could for example register a client
via dynamic client registration and intentionally send an 
erroneous authorization request, e.g. by using an invalid 
scope value, to cause the AS to automatically redirect the user
agent to its phishing site. 

The AS MUST take precautions to prevent this threat. 
Based on its risk assessment the AS needs to decide whether 
it can trust the redirect URI or not and should only automatically 
redirect the user agent, if it trusts the redirect URI. If not, it could
inform the user that it is about to redirect her to the another site 
and rely on the user to decide or just inform the user about the 
error. 

——

kind regards,
Torsten. 
  



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

[Torsten Lodderstedt]

Hi Brian,

> Am 20.03.2018 um 15:37 schrieb Brian Campbell :
> 
> +1 to what Travis said about 3.8.1
> 
> The text in 3.8 about Open Redirection is new in this most recent -05 version 
> of the draft so this is really the first time it's been reviewed. I believe 
> 3.8..1 goes too far in saying "this draft recommends that every invalid 
> authorization request MUST NOT automatically redirect the user agent to the 
> client's redirect URI." 
> 
> I understand that text was informed by 
> https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 
>  but it 
> takes one of the potential mitigation discussed there in section 3 
> 
>  (the one which happens to contradict RFC 6749) and elevates it to a "MUST". 
> I don't think something that drastic is warranted. I think there are other 
> mitigations - like strict redirect_uri matching,

In the attack described in 
https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 
 section 
2.1. the attacker dynamically registers a client with the AS. So exact redirect 
URI matching won’t stop the open redirection attack since the attacker uses the 
correct URI. The problem is with the change in the underlying trust model. RFC 
6749 assumes every configured client to be legit. This might have been ok at 
the time RFC 6749 was published. Open dynamic client registration collides with 
this assumption.   

We could distinguish between cases where the AS is confident the client is 
legit and other cases. But how does the AS determine it?

> referrer-policy headers, and appending a dummy fragment on error redirects -

Can you please explain how this protects from open redirection? 

> that can protect against the more serious redirection issues without 
> -security-topics trying to introduce normative breaking changes to the 
> behavior from the original OAuth 2.0 Authorization Framework. 


> 
> Perhaps there are some error cases not mentioned in RFC 6749 where returning 
> an HTTP error code to the browser would be better or more appropriate than 
> redirecting back to the OAuth client (my opinion on this has gone in circles 
> and I'm honestly not sure anymore). But saying that authorization requests 
> never automatically redirect back to the client's redirect URI is excessive.

Probably. Let’s discuss in detail. 

I think the AS should not automatically redirect the user in case of the 
following error conditions because an attacker could cause this errors via 
request parameters or its configuration:
- unsupported_response_type
- invalid_scope
- unauthorized_client
- invalid_request

kind regards,
Torsten. 

> 
> 
> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer  > wrote:
> I read through this doc and would like to share a bit of feedback in
> hopes that it helps:
> 
> * There is no mention of Content Security Policy (CSP). This is a very
> helpful security mechanism that all OAuth servers and web-based
> clients should implement. I think this needs to be addressed in this
> doc.
> - No mention of frame breaking scripts for non-CSP aware user agents
> -  No mention of X-Frame-Options
> * There's no mention of HSTS which all OAuth servers and web-based
> client should implement (or the reverse proxies in front of them
> should)
> * The examples only use 302 and don't mention that 303 is safer[1]
>- Despite what it says in section 1.7 of RFC 6749, many people
> think that a 302 is mandated by OAuth. It would be good to recommend a
> 303 and use examples with other status codes.
> * 3.3.1 refers to client.com  in the example. This is a 
> real domain.
> Suggest client.example.com  instead. Same issue 
> in 3.1.2 where
> client.evil.com  is used
> * 3.1.3 (proposed countermeasures) - native clients that use a web
> server with a dynamic port should use dynamic client registration and
> dynamic client management rather than allowing wildcards on the port
> matching of the OAuth server.
> * 3.8.1 says "Therefore this draft recommends that every invalid
> authorization request MUST NOT automatically redirect the user agent
> to the client's redirect URI" -- This is gonna break a lot of stuff
> including other specs! I don't think that's warranted, and I am not
> looking forward to the fallout this could cause.
> 
> Anyway, my $0.02. Hope it helps.
> 
> [1] https://arxiv.org/pdf/1601.01229v2.pdf 
> 
> 
> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan  > wrote:
> > Hi Torsten,
> >
> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> > Redirector" could 

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Torsten Lodderstedt]

We explicitly want the token (JSON object) to be signed not the HTTP response. 
I think using JWS is the most generic way to achieve that goal.

> Am 19.03.2018 um 09:57 schrieb Phil Hunt <phil.h...@oracle.com>:
> 
> This draft has similar issues to 
> https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 
> <https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01>
> 
> Rather than *try* sign HTTP, a signed JWT object is more reliably returned.
> 
> Phil
> 
> 
>> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis <louis.larmig...@wavestone.com 
>> <mailto:louis.larmig...@wavestone.com>> wrote:
>> 
>> Hi,
>>  
>> The draft Signing HTTP Messages <> 
>> (https://tools.ietf.org/html/draft-cavage-http-signatures-09 
>> <https://tools.ietf.org/html/draft-cavage-http-signatures-09>) could not 
>> meet this requirement in a more generic way ?
>>  
>> Regards,
>> Louis
>>  
>> De : OAuth <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> De la 
>> part de Brock Allen
>> Envoyé : dimanche 18 mars 2018 20:40
>> À : Torsten Lodderstedt <tors...@lodderstedt.net 
>> <mailto:tors...@lodderstedt.net>>; oauth@ietf.org <mailto:oauth@ietf.org>
>> Objet : Re: [OAUTH-WG] Fwd: New Version Notification for 
>> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>>  
>> Why is TLS to the intospection endpoint not sufficient? Are you thinking 
>> there needs to be some multi-tenancy support of some kind?
>>  
>> -Brock
>>  
>> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <tors...@lodderstedt.net 
>> <mailto:tors...@lodderstedt.net>> wrote:
>> 
>> Hi all,
>>  
>> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It 
>> proposes a JWT-based response type for Token Introspection. The objective is 
>> to provide resource servers with signed tokens in case they need 
>> cryptographic evidence that the AS created the token (e.g. for liability). 
>>  
>> I will present the new draft in the session on Wednesday.
>>  
>> kind regards,
>> Torsten. 
>> 
>> 
>> Anfang der weitergeleiteten Nachricht:
>>  
>> Von: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>> Betreff: New Version Notification for 
>> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>> Datum: 18. März 2018 um 20:19:37 MEZ
>> An: "Vladimir Dzhuvinov" <vladi...@connect2id.com 
>> <mailto:vladi...@connect2id.com>>, "Torsten Lodderstedt" 
>> <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>
>>  
>> 
>> A new version of I-D, 
>> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>> has been successfully submitted by Torsten Lodderstedt and posted to the
>> IETF repository.
>> 
>> Name:   draft-lodderstedt-oauth-jwt-introspection-response
>> Revision: 00
>> Title:  JWT Response for OAuth Token Introspection
>> Document date:  2018-03-15
>> Group:  Individual Submission
>> Pages:  5
>> URL:
>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>>  
>> <https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt>
>> Status: 
>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
>>  
>> <https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/>
>> Htmlized:   
>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00
>>  
>> <https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00>
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
>>  
>> <https://datatracker..ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>
>> 
>> 
>> Abstract:
>>   This draft proposes an additional JSON Web Token (JWT) based response
>>   for OAuth 2.0 Token Introspection.
>> 
>> 
>> 
>> 
>> 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 
>> <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>>  
>> The information transmitted in the present email including the attachment is 
>> intended only for the person to whom or ent

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Torsten Lodderstedt]

> Am 18.03.2018 um 20:40 schrieb Brock Allen <brockal...@gmail.com>:
> 
> Why is TLS to the intospection endpoint not sufficient?

TLS is sufficient, if AS and RS want to ensure the integrity of the token data 
(on transit). But there are use cases, where the RS wants evidence (== digital 
signature over the token) who created the token. This is for 
non-repudation/liability.

> Are you thinking there needs to be some multi-tenancy support of some kind?

With respect to what party? The draft allows every RS to choose the response 
type and if JWT, the algorithms to use. 

kind regards,
Torsten.   
 
> 
> -Brock
> 
>> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote:
>> 
>> Hi all,
>> 
>> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It 
>> proposes a JWT-based response type for Token Introspection. The objective is 
>> to provide resource servers with signed tokens in case they need 
>> cryptographic evidence that the AS created the token (e.g. for liability). 
>> 
>> I will present the new draft in the session on Wednesday.
>> 
>> kind regards,
>> Torsten. 
>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>>> Betreff: New Version Notification for 
>>> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>>> Datum: 18. März 2018 um 20:19:37 MEZ
>>> An: "Vladimir Dzhuvinov" <vladi...@connect2id.com 
>>> <mailto:vladi...@connect2id.com>>, "Torsten Lodderstedt" 
>>> <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>
>>> 
>>> 
>>> A new version of I-D, 
>>> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>>> has been successfully submitted by Torsten Lodderstedt and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-lodderstedt-oauth-jwt-introspection-response
>>> Revision:   00
>>> Title:  JWT Response for OAuth Token Introspection
>>> Document date:  2018-03-15
>>> Group:  Individual Submission
>>> Pages:  5
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>>>  
>>> <https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt>
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
>>>  
>>> <https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/>
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00
>>>  
>>> <https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00>
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
>>>  
>>> <https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>
>>> 
>>> 
>>> Abstract:
>>>   This draft proposes an additional JSON Web Token (JWT) based response
>>>   for OAuth 2.0 Token Introspection.
>>> 
>>> 
>>> 
>>> 
>>> 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 
>>> <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Torsten Lodderstedt]

Hi all,

I just submitted a new draft that Vladimir Dzhuvinov and I have written. It 
proposes a JWT-based response type for Token Introspection. The objective is to 
provide resource servers with signed tokens in case they need cryptographic 
evidence that the AS created the token (e.g. for liability). 

I will present the new draft in the session on Wednesday.

kind regards,
Torsten. 

> Anfang der weitergeleiteten Nachricht:
> 
> Von: internet-dra...@ietf.org
> Betreff: New Version Notification for 
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> Datum: 18. März 2018 um 20:19:37 MEZ
> An: "Vladimir Dzhuvinov" <vladi...@connect2id.com>, "Torsten Lodderstedt" 
> <tors...@lodderstedt.net>
> 
> 
> A new version of I-D, 
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name: draft-lodderstedt-oauth-jwt-introspection-response
> Revision: 00
> Title:JWT Response for OAuth Token Introspection
> Document date:2018-03-15
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
> Htmlized:   
> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
> 
> 
> Abstract:
>   This draft proposes an additional JSON Web Token (JWT) based response
>   for OAuth 2.0 Token Introspection.
> 
> 
> 
> 
> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

[Torsten Lodderstedt]

Hi all,

The new revision contains the following changes: 

Completed sections on code leakage via referrer header, attacks in browser, 
mix-up, and CSRF
Reworked Code Injection Section
Added reference to OpenID Connect spec
removed refresh token leakage as respective considerations have been given in 
section 10.4 of RFC 6749
first version on open redirection
incorporated Christian Mainka's review feedback

We think the document now covers recommendation on all (currently) relevant 
threats and is useful for all OAuth implementors and should be moved forward. 

kind regards,
Torsten. 

> Am 18.03.2018 um 20:12 schrieb internet-dra...@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 WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>    Authors     : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>   Filename: draft-ietf-oauth-security-topics-05.txt
>   Pages   : 27
>   Date: 2018-03-18
> 
> Abstract:
>   This document describes best current security practices for OAuth
>   2.0..  It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and cover new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IETF101 Draft Agenda

[Torsten Lodderstedt]

gorithm JWA [RFC7518] REQUIRED for encrypting introspection responses. If introspection_response_encrypted_response_algy is specified, the default for this value is A128CBC-HS256. When introspection_response_encrypted_response_enc is included, introspection_response_encrypted_response_alg MUST also be provided.


 

4. Acknowledgements

We would like to thank ...

5. IANA Considerations

TBD

6. Security Considerations

TBD

7. References


[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.


[RFC2246]

Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999.


[RFC7519]

Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.


[RFC7591]

Richer, J., Jones, M., Bradley, J., Machulak, M. and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015.


[RFC7662]

Richer, J., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015.


[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015.


[RFC7515]

Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.


[RFC7516]

Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015.


[OpenID.Registration]

NRIPing IdentityMicrosoft, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", Nov 2014.


Author's Address

  
	
	  Torsten Lodderstedt editor
	  
		Lodderstedt
	  
	
	YSES.com AG
	
	  
	  
		 
		
		
	  
	  
	
	EMail: tors...@lodderstedt.net

  



Am 09.03.2018 um 18:49 schrieb Torsten Lodderstedt <tors...@lodderstedt.net>:Can you please add the security topics to the agenda for Wednesday? I will publish -05 soon and I support your proposal to talk about a consensus call. Thanks, Torsten. Am 07.03.2018 um 19:53 schrieb Rifaat Shekh-Yusef <rifaat.i...@gmail.com>:Here is the draft agenda for our two sessions:Mondayhttps://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessaWednesdayhttps://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessbPlease, let us know if you have any comments.Regards, Rifaat & Hannes
___OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth___OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth