Re: [OAUTH-WG] Fwd: IETF 116 Preliminary Agenda

[Torsten Lodderstedt]

Hi Rifaat,

I'm flying back on Friday. I therefore would ask you to schedule the slot I 
asked for on Tuesday.
best regards,
Torsten.

On Feb. 25 2023, at 12:01 am, Rifaat Shekh-Yusef  
wrote:
> Based on the preliminary agenda, we have two official sessions:
> Tuesday and Friday, both at 9:30-11:30.
>
> Regards,
> Rifaat
>
>
> -- Forwarded message -
> From: IETF Agenda mailto:age...@ietf.org)>
> Date: Fri, Feb 24, 2023 at 5:50 PM
> Subject: IETF 116 Preliminary Agenda
> To: IETF Announcement List  (mailto:ietf-annou...@ietf.org)>
> Cc: mailto:i...@ietf.org)>, <116...@ietf.org 
> (mailto:116...@ietf.org)>
>
>
>
> IETF 116
> Yokohama, Japan
> March 25-31, 2023
> Hosted By: WIDE
>
>
> The IETF 116 Preliminary Agenda has been posted. The final agenda will be 
> published on Friday, March 3, 2023.
> https://datatracker.ietf.org/meeting/116/agenda.html
> https://datatracker.ietf.org/meeting/116/agenda.txt
>
> The preliminary agenda includes all planned WG, RG, and BoF sessions. 
> Information about side meetings will be available when the final agenda is 
> posted.
> IETF 116 Information: https://www.ietf.org/how/meetings/116/
> Register online at: https://registration.ietf.org/116/
>
> Don’t forget to register for these exciting IETF 116 events!
>
> Social Event
> The Osanbashi Pier's multipurpose hall will be transformed into a wonderful 
> social event location for IETF 116 attendees in Yokohama.
> Attendees will be delighted by the music of internationally renowned artist 
> Kaoru Watanabe, delicious food and a Japanese sake corner introducing 
> attendees to sake from all thirteen sake breweries in Kanagawa Prefecture.
> - Date: Thursday, March 30
> - Start/End Times: 19:00 – 21:30
> - Cost per ticket: $25 per ticket
> - Limit of tickets per attendee: Two per attendee.
> More information:
> https://www.ietf.org/how/meetings/116/social/
> https://ietf116.jp/social-event/
>
>
> Hackathon
> Onsite signup: https://registration.ietf.org/116/new/hackathon_onsite/
> Remote signup: https://registration.ietf.org/116/new/hackathon_remote/
> More information: 
> https://www.ietf.org/how/runningcode/hackathons/116-hackathon/
> Keep up to date by subscribing to: 
> https://www.ietf.org/mailman/listinfo/hackathon
>
>
> Code Sprint
> More information and signups: https://notes.ietf.org/notes-ietf-116-tools#
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org (mailto:ietf-annou...@ietf.org)
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>
>
> ___
> 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] IETF-116: Client/Trust Management

[Torsten Lodderstedt]

Thanks!Am 31.01.2023 um 18:36 schrieb Rifaat Shekh-Yusef :Hi Torsten,Sounds good. I will add this topic to the list.Regards, RifaatOn Tue, Jan 31, 2023 at 11:18 AM Torsten Lodderstedt <tors...@lodderstedt.net> wrote:Hi Rifaat, Kristina and I would like to give an update to the WG about challenges and developments on client/trust management in the context of decentralized identity at IETF-116.  We would seek the WG's feedback on our current ideas how to cope with them. We also think some of the ideas could be leveraged in other OAuth applications.This is a continuation of the session Kristian and Tobias held at the last meeting. 20 min would be much appreciated. best regards,Torsten. 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] IETF-116: Client/Trust Management

[Torsten Lodderstedt]

Hi Rifaat,

Kristina and I would like to give an update to the WG about challenges and 
developments on client/trust management in the context of decentralized 
identity at IETF-116. We would seek the WG's feedback on our current ideas how 
to cope with them. We also think some of the ideas could be leveraged in other 
OAuth applications.
This is a continuation of the session Kristian and Tobias held at the last 
meeting.
20 min would be much appreciated.
best regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

[Torsten Lodderstedt]

Hi Robert, 

Thanks for your review. 

> Am 15.12.2022 um 11:37 schrieb Robert Wilton via Datatracker 
> :
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-oauth-rar-20: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Apologies, but I was a bit short of time this week, and this is somewhat out 
> of
> my area, so I've only reviewed this as a light level.
> 
> I did have one question regarding the security considerations.  Are these JSON
> structures potentially susceptible to injection attacks if user input isn't
> properly sanitized and handled, and if so, should there be any text in the
> security section to warn of this?

Added the following text to the Security Considerations Section: 

"The AS MUST properly sanitized and handle the data passed in the
   authorization_details in order to prevent injection attacks.“

https://author-tools.ietf.org/iddiff?difftype=--hwdiff=draft-ietf-oauth-rar-21.txt

best regards,
Torsten. 

> 
> Regards,
> Rob
> 
> 
> 

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

Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

[Torsten Lodderstedt]

Hi Eric,

> Am 15.12.2022 um 11:33 schrieb Éric Vyncke via Datatracker :
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-oauth-rar-20: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-oauth-rar-19
> CC @evyncke
> 
> Thank you for the work put into this document. It is very easy to read and
> quite powerful.
> 
> Please find below one non-blocking COMMENT point (rather a suggestion).
> 
> Special thanks to Hannes Tschofenig for the shepherd's detailed write-up
> including the WG consensus ***but*** missing the justification of the intended
> status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> ### Section 1
> 
> I like the use of EUR rather than USD ;-)

:-) 

> 
> Suggest to also add "bic" in addition to "iban" to be consistent with
> https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

added bic the example (even though it’s not required for German bank accounts 
even cross border ;-))

https://author-tools.ietf.org/iddiff?difftype=--hwdiff=draft-ietf-oauth-rar-21.txt

thanks,
Torsten. 

> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 
> 
> 

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

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-rar-19: (with COMMENT)

[Torsten Lodderstedt]

Hi Murray, 

thanks for you review. 

I updated the draft based on it and submitted -20

Here is the diff 
https://author-tools.ietf.org/iddiff?difftype=--hwdiff=draft-ietf-oauth-rar-20.txt

> Am 15.12.2022 um 09:34 schrieb Murray Kucherawy via Datatracker 
> :
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-oauth-rar-19: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for the work put into this.  Seems like it's in good shape.
> 
> Thank you to Thomas Fossati for the ARTART review.
> 
> "MUST consider" in Section 3.1 is curious.  How does an implementation comply
> with something like "consider"?

Good point, what we want to get across is that the AS must not ignore any of 
the requirements defined in a scope or authorization details parameter if both 
are present in the authorisation request. 

Changed it to „process".

> 
> Why is the "RECOMMENDED" in Section 9.1 not a MUST?  The text in Section 9 
> just
> above it suggest something stronger.

The AS is free to choose the format and representation of the data. It is not 
required to use the authorization details structure, it can transform and 
filter it. 

> 
> In Section 7.1, I can't understand what's meant by "This mechanic ...".

Changed it to „This example“. 

best regards,
Torsten.   

> 
> 
> 

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

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-rar-15

[Torsten Lodderstedt]

Hi Carl,

thanks for your review comments.

> Am 16.11.2022 um 12:25 schrieb Carl Wallace via Datatracker 
> :
> 
> Reviewer: Carl Wallace
> Review result: Has Nits
> 
> Comments/questions
> - Section 2.2 states "When different common data fields are used in
> combination, the permissions the client requests are the cartesian product of
> the values." What would that mean for the example in Figure 7 where 
> geolocation
> is asserted?

The example in figure 7 asks for read and write access to metadata and images 
managed by a photo api offered at two different endpoints if the geo locations 
in the respective pictures are at one of the coordinates given in the 
geolocations array.

> Are data fields other than the common types not processed this
> way?

Yes, they are. 

> - The MUST in the first sentence of the third paragraph in Section 3.1
> should probably be a SHOULD.

From an interoperability standpoint, it is important the client can expect the 
AS to consider both sets of requirements.

> The paragraph before recommends against using both
> scope and authorization_details.

for the same API. However, if the same client asks for access to multiple APIs 
in the same authorization request and different APIs use one or the other 
method, that is nevertheless be supported by the spec. That’s also important to 
allow pre-existing APIs and new APIs to co-exist. 

For example, OpenID Connect uses scopes but newer APIs for Open Banking might 
use RAR. Asking for identity claims and the permission to execute a payment in 
the same transaction might make a lot of sense. 

> The rest of the paragraph leaves open how to
> handle the combination (presumably including ignoring one or the other).

The normative requirement is to support both in the same authorization request. 

> - It
> is unclear to me how the "MUST consider both sets of requirements in
> combination with each other" language in Section 3.2 squares with the 
> "resource
> parameter does not have any impact on the way the AS processes the
> authorization_details" language in Section 3.3 for  a request that includes
> scope, resource and authorization_details w/locations. If scope and resource
> were used before, it seems odd to only consider scope during a migration
> period.

good point. What we want to get across is: Whatever was valid before, is not 
rendered invalid by RAR. scope and resource can be combined as defined in RFC 
8707 - that's the first sentence. What 3.2 tries to convey is that while the 
resource has an impact on the interpretation of the scope, it does not have any 
impact on the authorization details - that’s the second sentence. 

> - In section 7, the first paragraph has a MUST regarding sending "the
> authorization details as granted by the resource owner". The third paragraph
> leaves room for discretion. Should the MUST be a SHOULD?

That makes sense. Changed the wording to MUST. 

> 
> Nits
> - Expand AS and RS on first use

done

> - The security considerations should echo the requirement that the AS ensure
> that there is no collision between different authorization details types that
> it supports.

added sentence to the second paragraph in the security considerations section

> - In section 6, the bulleted list of privileges is incomplete. The
> example in Section 3 also allowed for checking the status of and canceling a
> payment.

added

> - Section 11.1 should probably include a bullet regarding client use
> of the authorization_details_types metadata.

Added “(if needed) Entitle clients to use certain authorization details types” 

> - In the second paragraph of
> Section 12, "all strings" should probably be "all strings in an
> authorization_details parameter".

done 

I published a new revision with all changes 
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-16.html 


best regards,
Torsten. 


> 
> 
> 

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

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

[Torsten Lodderstedt]

+1 I support adoption of this draft.

> Am 22.11.2022 um 01:44 schrieb Justin Richer :
> 
> I support adoption of this draft. It’s important work that affects a number 
> of areas in and around OAuth.
> 
>  — Justin
> 
>> On Nov 15, 2022, at 6:43 AM, Rifaat Shekh-Yusef > > wrote:
>> 
>> All,
>> 
>> During the IETF meeting last week, there was a strong support for the 
>> adoption of the following document as a WG document:
>> https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/ 
>> 
>> 
>> This is to start a call for adoption for this document. 
>> Please, provide your feedback on the mailing list on whether you support the 
>> adoption of this document as a WG or not, by Nov 29th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

[Torsten Lodderstedt]

Hi Roman, 

I just published revision -14 with the all the agreed changes.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html

best regards,
Torsten. 

> Am 24.10.2022 um 13:07 schrieb Roman Danyliw :
> 
> Hi Torsten!
> 
> Thanks for the response.  More inline ...
> 
>> -Original Message-
>> From: Torsten Lodderstedt > <mailto:tors...@lodderstedt.net>>
>> Sent: Tuesday, October 18, 2022 9:00 AM
>> To: Roman Danyliw mailto:r...@cert.org>>
>> Cc: oauth@ietf.org <mailto:oauth@ietf.org>; Brian Campbell 
>> mailto:bcampb...@pingidentity.com>>;
>> jric...@mit.edu <mailto:jric...@mit.edu>
>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
>> 
>> Hi Roman,
>> 
>> thanks for you review.
>> 
>> I’m trying to do the next round for the outstanding issues you raised.
>> 
>>> Am 15.09.2022 um 00:30 schrieb Roman Danyliw :
>>> 
>>> Hi!
>>> 
>>> I performed an AD review of draft-ietf-oauth-rar-12.  Thanks for this
>> document.  My feedback is as follows:
>>> 
>>> ** Section 2. Editorial
>>> 
>>> This field MUST be compared using an exact byte match of the string
>>>  value against known types by the AS.
>>> 
>>> Consider if you want to introduce how the lack of match will be handled here
>> - it is covered later.
>> 
>> I’m not sure how to handle this as there is no direct consequence (in the 
>> sense
>> of error condition) other then that different byte arrays constitute 
>> different
>> types.
>> 
>> We could state something like this: "String values with different byte
>> representations constitute different types.“ ?
> 
> Works for me.
> 
>>> 
>>> ** Section 2.2.
>>> 
>>> All data fields are OPTIONAL for use by a given API
>>>  definition.
>>> 
>>> I don't follow how this is true in the general case.  I was under the 
>>> impression
>> that this section defined what is expected to be common fields.  Couldn't 
>> some
>> AS with a particular type require their presence?
>>> 
>>> ** Section 3.  Editorial
>>> 
>>> OLD
>>> In case of authorization requests as defined in [RFC6749],
>>>  implementors MAY consider to use
>>> 
>>> NEW
>>> In case of authorization requests as defined in [RFC6749],
>>>  implementors MAY consider using ...
>>> 
>>> ** Section 3.  Typo. s/intiate/initiate/
>>> 
>>> ** Section 5.  Typo.
>>> 
>>> OLD
>>> authorization details type
>>>  or authorization details
>>> 
>>> NEW
>>> authorization_details type
>>>  or authorization_details
>> 
>> The spec uses authorization details types to refer to the general concept and
>> authorization_details to refer to the parameter. I think the former is
>> appropriate at this place.
> 
> Understood.
> 
>>> 
>>> ** Section 6.1
>>> 
>>> However, when comparing a new request to an existing request,
>>>  authorization servers can use the same processing techniques as used
>>>  in granting the request in the first place to determine if a resource
>>>  owner needs to authorize the request.
>>> 
>>> Why is it possible to assess two arbitrary requests in this case to 
>>> determine "if
>> a resource owner needs to authorize the request", but the prior paragraph
>> explicitly calls out that comparing two arbitrary requests is not feasible?  
>> To me
>> is seems like comparing two requests to understand if more or less 
>> permissions
>> are being requested is equivalent to determining if a new request exceed the
>> current request to determine if going back to the resource owner is needed.
>>> 
>>> ** Section 6.1.  Typo. s/isaunce/issuance/
>>> 
>>> ** Section 7.
>>> 
>>>  If the client does not specify
>>>  the authorization_details token request parameters, the AS determines
>>>  the resulting authorization details at its discretion.  The
>>>  authorization server MAY consider the values of other parameters such
>>>  as resource and scope if they are present during this processing, and
>>>  the details of such considerations are outside the scope of this
>>>  specification.
>>> 
>>> This guidance seems to indicate the use of the scope parameter is optional 
>>> in
>> determining the authorization details.  Sect

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

[Torsten Lodderstedt]

Hi Roman, 

thanks for you review. 

I’m trying to do the next round for the outstanding issues you raised.

> Am 15.09.2022 um 00:30 schrieb Roman Danyliw :
> 
> Hi!
> 
> I performed an AD review of draft-ietf-oauth-rar-12.  Thanks for this 
> document.  My feedback is as follows:   
> 
> ** Section 2. Editorial
> 
> This field MUST be compared using an exact byte match of the string
>   value against known types by the AS.
> 
> Consider if you want to introduce how the lack of match will be handled here 
> - it is covered later.

I’m not sure how to handle this as there is no direct consequence (in the sense 
of error condition) other then that different byte arrays constitute different 
types. 

We could state something like this: "String values with different byte 
representations constitute different types.“ ? 

> 
> ** Section 2.2.
> 
> All data fields are OPTIONAL for use by a given API
>   definition.  
> 
> I don't follow how this is true in the general case.  I was under the 
> impression that this section defined what is expected to be common fields.  
> Couldn't some AS with a particular type require their presence?
> 
> ** Section 3.  Editorial
> 
> OLD
> In case of authorization requests as defined in [RFC6749],
>   implementors MAY consider to use
> 
> NEW
> In case of authorization requests as defined in [RFC6749],
>   implementors MAY consider using ...  
> 
> ** Section 3.  Typo. s/intiate/initiate/
> 
> ** Section 5.  Typo.
> 
> OLD
> authorization details type
>   or authorization details
> 
> NEW
> authorization_details type
>   or authorization_details

The spec uses authorization details types to refer to the general concept and 
authorization_details to refer to the parameter. I think the former is 
appropriate at this place. 

> 
> ** Section 6.1
> 
>  However, when comparing a new request to an existing request,
>   authorization servers can use the same processing techniques as used
>   in granting the request in the first place to determine if a resource
>   owner needs to authorize the request.   
> 
> Why is it possible to assess two arbitrary requests in this case to determine 
> "if a resource owner needs to authorize the request", but the prior paragraph 
> explicitly calls out that comparing two arbitrary requests is not feasible?  
> To me is seems like comparing two requests to understand if more or less 
> permissions are being requested is equivalent to determining if a new request 
> exceed the current request to determine if going back to the resource owner 
> is needed.
> 
> ** Section 6.1.  Typo. s/isaunce/issuance/
> 
> ** Section 7.
> 
>   If the client does not specify
>   the authorization_details token request parameters, the AS determines
>   the resulting authorization details at its discretion.  The
>   authorization server MAY consider the values of other parameters such
>   as resource and scope if they are present during this processing, and
>   the details of such considerations are outside the scope of this
>   specification.
> 
> This guidance seems to indicate the use of the scope parameter is optional in 
> determining the authorization details.  Section 3.1 says "The AS MUST 
> consider both sets of requirements in combination with each other for the 
> given authorization request."  My read is that this is conflicting guidance 
> and Section 3.1 is correct.

Justin: „You aren’t required to use “scope” in order to use 
“authorization_details”, but we do want to say that the AS is allowed to (or 
even is supposed to) consider both “scope” and “authorization_details” when 
determining the resulting access for any given request that might have both. 
The guidance in 3.1 should probably say “the AS MUST consider all requirements 
present on a request” or something like that?“

Section 3 already states that the AS must consider scope and resource in 
addition to authorisation details. I suggest to drop that sentence entirely.

> 
> ** Figure 15.  The text prior to this figure says that for "For our running 
> example, this would look like this" indicating that this figure is similar to 
> previous examples.  There is one key different - this is the first use of a 
> "payment_initiator" type with the API URL prepended.
> 
> ** Section 7.1. Typo. s/sub set/subset/
> 
> ** Section 8.  What is the difference between this section and Section 5 
> beyond this text explicitly stating the name of the error value 
> (invalid_authorization_details).  I'd recommend stating the normative 
> behavior twice; that is, why are both sections needed?

5 and 8 define the error behaviour of different endpoint. But you are right, 
the text is the same (with 5 being even more detailed). Suggest to remove the 
text in 8 with a reference to 5.

best regards,
Torsten. 

> 
> ** Section 9.2.  Editorial.  There is some kind of rendering issues in the 
> RFC7622 reference.  It reads "[!@RFC7662]".
> 
> ** Section 11.2.  
> 
>   Products supporting this specification should 

Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[Torsten Lodderstedt]

Hi, 

the consent is not bound to the code. As you correctly pointed out, the code is 
a temporary artifact. It’s purpose is to bridge insecure frontchannel 
communication to more secure backchannel communication. You don’t need to 
preserve the code in order to preserve the consent. The code is merely intended 
to be a reference to the consent (or grant). So even if the code expires, the 
consent can be preserved and updated in the AS. In the simplest case, it is 
transferred to the refresh token. In more sophisticated implementations, the 
consent is a first class object in the AS. 

best regards,
Torsten.  

> Am 19.08.2022 um 16:23 schrieb Jaimandeep Singh 
> :
> 
> Hi Karsten,
> 
> Thx a lot for all the time and effort in explaining the things. This brings 
> up an important discussion point as we are revising OAuth 2.0. Do we need to 
> make the authorization code a temporary token? Section 1.3.1 of the draft RFC 
> states:
> An authorization code is a temporary credential used to obtain an access 
> token. 
> Here, I am only considering the case of human interaction where it is 
> necessary to take the consent of the human (resource owner) before granting 
> access to his protected resources. As I have already mentioned in the trail 
> mail, OAuth is a two step process: Step 1: Take consent from the user. Step 
> 2: Handover that consent to the third party to access resources on the user's 
> behalf. 
> 
> Now, if we make authorization code a temporary artifact, we will never be 
> able to go back to the previous step and will have to per-force start the 
> process again. Now, with RFC 8705 client applications can be identified with 
> the private key, which are also of rotating nature. We also have DPoP and 
> certificate thumbprints coming up. Then, how wise it is to discard this 
> important token and start all over again.
> 
> So, my recommendation is not to make the authorization code temporary 
> especially when used with DPoP and thumbprint cnf. This will reduce the 
> headache of asking the consent from a human user because the refresh token 
> expired.
> 
> For kind consideration of the members please.
> 
> Regards and Best Wishes
> Jaimandeep Singh 
> 
> On Fri, Aug 19, 2022 at 7:07 PM Karsten Meyer zu Selhausen 
>  > wrote:
> Hi Jaimandeep,
> 
> I disagree with both of your points. See my comments inline.
> 
> Best regards,
> Karsten
> 
> On 12.08.2022 05:40, Jaimandeep Singh wrote:
>> Hi Mikheil,
>> 1. Well explained by Brain. I will just add my perspective.
>> >From the practical perspective, if the confidential client got a refresh
>> token for the offline access and sufficient time (e.g., for a month), this
>> would be quite impractical and not very user-friendly to ask a lot of users
>> to give consents again when the confidential client wants to upgrade its
>> certificate. But seems like software vendors did not interpret the RFC that
>> way.
>> For confidential clients, authorization code flow is recommended. It is a 
>> two step process. In the first step you get the authorization code when the 
>> user provides his/her consent. In the second step you use this authorization 
>> code along with client credentials to obtain access tokens and refresh 
>> tokens. If the refresh token expires either due to expiry of its lifetime or 
>> certificate, it only needs to follow step two. So, the question of asking 
>> for consent again does not arise unless the authorization code itself has 
>> limited lifespan.
> IMHO authorization codes should always be implemented as one-time-use tokens. 
> Even when there is a grace period allowing a client to redeem a code a second 
> time (e.g., in case of network failure) this period should be very short - 
> much shorter than the validity of refresh tokens in practice.
> 
> If the refresh token is expired, the client should start a new authorization 
> flow and ask the user for consent again unless the AS provides a way for 
> users to grant access for clients "permanently".
> 
>> 
>> 2.
>> While RFC 8705 indeed requires binding refresh token to the certificate in
>> case of the public clients in Section 4 and Section 7.1
>> The RFC 8705 talks about public clients and refresh tokens in the same 
>> breath and seems to have legitimized the use of refresh tokens for public 
>> clients. However, if we look at the original OAuth 2.0 specifications RFC 
>> 6749, Section 4.2, talks about implicit grant optimized for 
>> public clients. It does not support issuing refresh tokens by AS in the 
>> first place. I think there is a need to deliberate on this issue in the next 
>> update / errata  for RFC 8705.
> RFC 6749 is much older than RFC 8705. Both drafts "OAuth 2.0 Security Best 
> Current Practice" (hopefully soon to be finished) and OAuth 2.1 deprecate 
> issuing access tokens from the authorization endpoint (which is more or less 
> the implicit grant). Today's best practice is to use the 

Re: [OAUTH-WG] DPoP - IPR Disclosure

[Torsten Lodderstedt]

I also am unaware of any IPR.

best regards,
Torsten.

> Am 11.08.2022 um 05:54 schrieb David Waite 
> :
> 
> I also am unaware of any IPR.
> 
> -DW
> 
>> On Aug 10, 2022, at 3:37 PM, Rifaat Shekh-Yusef  
>> wrote:
>> 
>> Daniel, Brian, John, Torsten, Mike, and David,
>> 
>> As part of the shepherd write-up for the DPoP document, there is a need for 
>> an IPR disclosure from the authors.
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>> 
>> Are you aware of any IPRs associated with this document?
>> 
>> Regards,
>>  Rifaat & Hannes
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 19:30 schrieb David Chadwick 
> :
> 
> 
> Hi Torsten
> 
> your use case sounds like an online use case, not an offline one. So its a 
> question of balancing a long lived SD-JWT along with a revocation mechanism 
> vs a short lived minimal JWT containing just the claims that are needed.
> 
That’s correct. 
> I thought that SAML, OAuth2 and OIDC had opted for short lived non-revocable 
> claims rather than long lived revocable ones due to the experiences of using 
> revocation with X.509 PKCs.
> 
SAML and OIDC are considerably simple, flexible, and secure solutions to the 
challenges of selective disclosure, direct identifiers, and current claim 
values. They are an excellent solution for Web SSO. However, they require the 
IDP to be always on, an online connection to the RP, and share a lot of 
metadata with the IDP. 

X.509 certificate never had those problems, but are inflexible and require 
revocation. Verifiable Credentials to me are more like X.509 certs but with 
more flexibility, simpler to use data formats, and the option to selectively 
disclose claims.

So the question merely is what parameters to optimize for.

The current thinking I perceive is to give users long lived credentials, which 
means the issuer doesn’t need to be always on, there is no need for online 
connection, and the issuer does not get any metadata on when, what kind of 
claims is being used. This also makes offline use of such credentials an 
obvious option.

However, the lifecycle of such credentials needs to be managed. I think 
revocation lists are an ok solution to that problem. I don’t see how the issuer 
could learn where a credential is being used with revocation lists as the 
verifier will just download the whole list for evaluation and revocation lists 
typically do not authenticate the verifier. Which leaves the IP address of the 
verifier as metadata without any further context.

I think the issuer part of it is more complex than people currently believe 
since issuers need to maintain a list of the credentials they issued (not 
needed in OIDC). Updates to credential data need to be published and last but 
not least, there needs to be away to let credentials be revoked. E.g. an user 
or a wallet provider might need to ask an issuer to revoke a certain credential 
because of abuse. That’s gone be though.

That might be the reason why ISO mDL uses expiration (I guess weeks to month) 
instead of revocation. And the wheel starts to turn again …
> Kind regards
> 
> David
> 
> On 02/08/2022 10:47, Torsten Lodderstedt wrote:
>> 
>>>> Am 02.08.2022 um 11:06 schrieb Warren Parad :
>>>> 
>>>> I was following your train of thought, let me paste that here for 
>>>> transparency, you specifically said:
>>>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>>>>> tokens (those could be short lived) that effectively are verifiable 
>>>>> presentations (based on a verifiable credential) audience restricted for 
>>>>> a certain RS. The client wouldn’t even know it’s a verifiable 
>>>>> presentation since the access token is opaque to the client.
>>>> 
>>>> Which I replied:
>>>>> If the user's wallet acts as the AS issuing tokens, then there is zero 
>>>>> need for this draft because we could pass the scopes that relate to the 
>>>>> claims directly to the AS, and have the AS return a limited JWT, and we 
>>>>> would actually do that every time because:
>>>>> we can
>>>>> because the tokens have short lifetime
>>>>> So that isn't a valid argument, unless there's a reason why the AS 
>>>>> wouldn't be able to do this.
>>>> 
>>>> In this conversation, I'm still not able to parse what you are saying. 
>>>> Yes, of course the user having a physical device (as the AS) to issue 
>>>> tokens is privacy enhancing, but then we don't need this draft as I just 
>>>> proved. Or are you talking about a different point?
>>> 
>>> In the model I envision, OAuth clients are able to obtain access tokens for 
>>> the user’s services through the user’s wallet. Since the wallet is not the 
>>> AS the RS trusts, I would like to utilize verifiable credentials as basis 
>>> for issuing access tokens from the wallet. That means the credential is 
>>> issued by the AS and the wallet can mint access tokens containing a 
>>> presentation of such a credential. From a RSs standpoint this retains the 
>>> standard trust model since the RS only accepts access tokens containing a 
>>> credential from an AS it trusts. 
>>> 
>>> 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 11:44 schrieb David Chadwick 
> :
> 
> 
> 
> On 01/08/2022 18:39, Warren Parad wrote:
>> So the question is how many offline interactions are there, and what do 
>> those look like?
> This to me is the key question. If the vast majority of transactions between 
> the user/wallet and the RP are online (which I believe that most will be), 
> then the client/wallet/user can request a short lived credential on demand 
> from the RS containing just the claims that the RP is requesting. The same 
> access token should be usable for this. This also solves the pair-wise ID 
> issue between the wallet/user and the RP, as the user's key inserted into the 
> credential will be ephemeral.
> 
> 

That is certainly feasible and it would solve selective disclosure and 
unlinkability on the RP side. 

However, it comes at a price. It will tell the issuer a lot about the 
frequency, the time, and the claims a user uses for accessing service, 
degrading privacy towards issuers. 

That’s the reason I would not expect a lot of deployments to embrace this 
pattern. e.g. I would doubt eIDAS 2 goes that way. 
> For those (possible few) transactions in which the wallet is offline, then 
> the wallet has to obtain the (possibly selectively disclosed) credential 
> before it is needed. But this is already the case today with boarding passes. 
> I load it onto my phone whilst I am online at home, and then I present it 
> offline at the airport e.g. via a QR code. So using this model the user can 
> go to the RS when online, obtain a short lived selectively disclosed 
> credential that they know will be needed later (e.g. age over 18 for entering 
> a nightclub) and then present it offline when they arrive at the nightclub.
> 
> For those (possibly even fewer) transactions in which the user is suddenly 
> caught offline e.g. on the top of a mountain by a police officer, then I can 
> see that the SD-JWT with blinded property names and values is a suitable 
> solution. The user might have a few of these in their wallet, each being 
> one-time use with a different key, that once selectively disclosed are 
> discarded. The user/wallet can refresh the store periodically (or the wallet 
> could do this automatically ensuring that a small number are always present). 
> These would also need to be relatively short lived otherwise a revocation 
> mechanism would need to be introduced (horror of horrors, especially on the 
> top of a mountain with no access to the revocation list).
> 
> Kind regards
> 
> David
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 11:06 schrieb Warren Parad :
> 
> I was following your train of thought, let me paste that here for 
> transparency, you specifically said:
> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
> tokens (those could be short lived) that effectively are verifiable 
> presentations (based on a verifiable credential) audience restricted for a 
> certain RS. The client wouldn’t even know it’s a verifiable presentation 
> since the access token is opaque to the client.
> 
> Which I replied:
> If the user's wallet acts as the AS issuing tokens, then there is zero need 
> for this draft because we could pass the scopes that relate to the claims 
> directly to the AS, and have the AS return a limited JWT, and we would 
> actually do that every time because:
> we can
> because the tokens have short lifetime
> So that isn't a valid argument, unless there's a reason why the AS wouldn't 
> be able to do this.
> 
> In this conversation, I'm still not able to parse what you are saying. Yes, 
> of course the user having a physical device (as the AS) to issue tokens is 
> privacy enhancing, but then we don't need this draft as I just proved. Or are 
> you talking about a different point?

In the model I envision, OAuth clients are able to obtain access tokens for the 
user’s services through the user’s wallet. Since the wallet is not the AS the 
RS trusts, I would like to utilize verifiable credentials as basis for issuing 
access tokens from the wallet. That means the credential is issued by the AS 
and the wallet can mint access tokens containing a presentation of such a 
credential. From a RSs standpoint this retains the standard trust model since 
the RS only accepts access tokens containing a credential from an AS it trusts. 

I also assume that a single AS is managing access to several RSs as that was 
the case in almost all deployments I was involved with. 

I think the most efficient and flexible way to implement this scenario is to 
issue a single SD-JWT based credential and to mint RS-specific access token as 
needed by using SD-JWT’s selective disclosure capabilities. So an access token 
for the user’s contacts API would only include the claims needed for this 
service (e.g. the privilege to use the service) whereas an access token for the 
streaming API would include the data needed there (e.g. authorised channel 
lists and so on). 

> 
> On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt 
>  <mailto:40lodderstedt@dmarc.ietf.org>> wrote:
> 
> 
>> Am 02.08.2022 um 10:48 schrieb Warren Parad 
>> mailto:40rhosys...@dmarc.ietf.org>>:
>> 
>> 
>> Can you please reread what you wrote and rephrase it differently? Telling us 
>> to look at the OAuth JWT RFC isn't helpful here.
> 
> You say the AS can issue an access token every time and I say the wallet can 
> issue access tokens on its own without the need to go back to the AS every 
> time again. That’s privacy enhancing and helps scalability.
> 
>> Also it isn't clear which part of your statement you are trying to clarify. 
>> What does "original AS" mean? Are you suggesting a "multi AS" configuration? 
>> What does that look like?
>> 
>> On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt 
>> > <mailto:40lodderstedt@dmarc.ietf.org>> wrote:
>> 
>> 
>>> Am 02.08.2022 um 10:35 schrieb Warren Parad 
>>> mailto:40rhosys...@dmarc.ietf.org>>:
>>> 
>>> 
>>> Why would we not include those seemingly critical details in the draft then?
>>> Let's define what a verifiable presentation is (is that already defined 
>>> somewhere? I didn't see it in the draft)
>>> Require the JWTs to be signed with a private key from a certificate chain, 
>>> and include the whole certificate chain in the body. (I don't think there 
>>> is already a RFC for this, but I could be wrong)
>>> Let's also talk about this comment:
>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>>> tokens (those could be short lived) that effectively are verifiable 
>>> presentations (based on a verifiable credential) audience restricted for a 
>>> certain RS. The client wouldn’t even know it’s a verifiable presentation 
>>> since the access token is opaque to the client.
>>> 
>>> If the user's wallet acts as the AS issuing tokens, then there is zero need 
>>> for this draft because we could pass the scopes that relate to the claims 
>>> directly to the AS, and have the AS return a limited JWT, and we would 
>>> actually do that every time because:
>>> we can
>>> because the tokens have short lifeti

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 10:48 schrieb Warren Parad 
> :
> 
> 
> Can you please reread what you wrote and rephrase it differently? Telling us 
> to look at the OAuth JWT RFC isn't helpful here.

You say the AS can issue an access token every time and I say the wallet can 
issue access tokens on its own without the need to go back to the AS every time 
again. That’s privacy enhancing and helps scalability.

> Also it isn't clear which part of your statement you are trying to clarify. 
> What does "original AS" mean? Are you suggesting a "multi AS" configuration? 
> What does that look like?
> 
>> On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt 
>>  wrote:
>> 
>> 
>>>> Am 02.08.2022 um 10:35 schrieb Warren Parad 
>>>> :
>>>> 
>>> 
>>> Why would we not include those seemingly critical details in the draft then?
>>> Let's define what a verifiable presentation is (is that already defined 
>>> somewhere? I didn't see it in the draft)
>>> Require the JWTs to be signed with a private key from a certificate chain, 
>>> and include the whole certificate chain in the body. (I don't think there 
>>> is already a RFC for this, but I could be wrong)
>>> Let's also talk about this comment:
>>>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>>>> tokens (those could be short lived) that effectively are verifiable 
>>>> presentations (based on a verifiable credential) audience restricted for a 
>>>> certain RS. The client wouldn’t even know it’s a verifiable presentation 
>>>> since the access token is opaque to the client.
>>> 
>>> If the user's wallet acts as the AS issuing tokens, then there is zero need 
>>> for this draft because we could pass the scopes that relate to the claims 
>>> directly to the AS, and have the AS return a limited JWT, and we would 
>>> actually do that every time because:
>>> we can
>>> because the tokens have short lifetime
>>> So that isn't a valid argument, unless there's a reason why the AS wouldn't 
>>> be able to do this.
>> 
>> Well, how many access tokens have you seen in the wild that only contain an 
>> access token? I haven’t, any of the carriers some for of user claims, e.g. a 
>> sub, in most cases some privileges/roles. Please take a look at 
>> https://www.rfc-editor.org/rfc/rfc9068.html for best current practice.
>> 
>> Using a VC in the way I described means the original AS doesn’t need to be 
>> involved in the
>> 
>>> 
>>>> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt 
>>>>  wrote:
>>>> 
>>>> 
>>>>>> Am 02.08.2022 um 09:53 schrieb Warren Parad 
>>>>>> :
>>>>>> 
>>>>> 
>>>>> If we are in a offline scenario how does the verifier got ahold of the 
>>>>> public key associated with the id token?
>>>> 
>>>> Why id token? I would assume we are talking about verifiable 
>>>> presentations, right?
>>>> 
>>>> There are a couple of ways to provide the verifier with the public key 
>>>> needed to verify. The (raw) key could be contained in the credential or 
>>>> the presentation. If a trust chain is required, a x.509 certificate could 
>>>> serve the same purpose.
>>>> 
>>>> Beside that offline has different facets. In a Point of Sales scenario, 
>>>> even though the wallet would be offline the checkout counter would most 
>>>> likely have connectivity. That would also allow to resolve the public key 
>>>> on demand.
>>>> 
>>>>> 
>>>>> They would need to be online, that defeats any benefit this could provide.
>>>>> 
>>>>> Or what if the token you have expires. Many providers issue tokens only 
>>>>> good for 1 hour. If that expires, the user has to go through the online 
>>>>> flow again.
>>>>> 
>>>>> Unless we can add some provisions to ensure long lived token validity, I 
>>>>> think in practice we're cripling the usefulness.
>>>> 
>>>> Absolutely. That’s the reason a verifiable credential has a much longer 
>>>> lifetime simply because the user should be able to use it in a sensible 
>>>> way. As this makes replay more likely, all verifiable credentials formats 
>>>> utilize holder binding for reply detection. The public key mentioned above 
>>>> is part o

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 10:35 schrieb Warren Parad 
> :
> 
> 
> Why would we not include those seemingly critical details in the draft then?
> Let's define what a verifiable presentation is (is that already defined 
> somewhere? I didn't see it in the draft)
> Require the JWTs to be signed with a private key from a certificate chain, 
> and include the whole certificate chain in the body. (I don't think there is 
> already a RFC for this, but I could be wrong)
> Let's also talk about this comment:
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>> tokens (those could be short lived) that effectively are verifiable 
>> presentations (based on a verifiable credential) audience restricted for a 
>> certain RS. The client wouldn’t even know it’s a verifiable presentation 
>> since the access token is opaque to the client.
> 
> If the user's wallet acts as the AS issuing tokens, then there is zero need 
> for this draft because we could pass the scopes that relate to the claims 
> directly to the AS, and have the AS return a limited JWT, and we would 
> actually do that every time because:
> we can
> because the tokens have short lifetime
> So that isn't a valid argument, unless there's a reason why the AS wouldn't 
> be able to do this.

Well, how many access tokens have you seen in the wild that only contain an 
access token? I haven’t, any of the carriers some for of user claims, e.g. a 
sub, in most cases some privileges/roles. Please take a look at 
https://www.rfc-editor.org/rfc/rfc9068.html for best current practice.

Using a VC in the way I described means the original AS doesn’t need to be 
involved in the issuance of the actual access token, which adds to privacy and 
scalability.

> 
>> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt 
>>  wrote:
>> 
>> 
>>>> Am 02.08.2022 um 09:53 schrieb Warren Parad 
>>>> :
>>>> 
>>> 
>>> If we are in a offline scenario how does the verifier got ahold of the 
>>> public key associated with the id token?
>> 
>> Why id token? I would assume we are talking about verifiable presentations, 
>> right?
>> 
>> There are a couple of ways to provide the verifier with the public key 
>> needed to verify. The (raw) key could be contained in the credential or the 
>> presentation. If a trust chain is required, a x.509 certificate could serve 
>> the same purpose.
>> 
>> Beside that offline has different facets. In a Point of Sales scenario, even 
>> though the wallet would be offline the checkout counter would most likely 
>> have connectivity. That would also allow to resolve the public key on demand.
>> 
>>> 
>>> They would need to be online, that defeats any benefit this could provide.
>>> 
>>> Or what if the token you have expires. Many providers issue tokens only 
>>> good for 1 hour. If that expires, the user has to go through the online 
>>> flow again.
>>> 
>>> Unless we can add some provisions to ensure long lived token validity, I 
>>> think in practice we're cripling the usefulness.
>> 
>> Absolutely. That’s the reason a verifiable credential has a much longer 
>> lifetime simply because the user should be able to use it in a sensible way. 
>> As this makes replay more likely, all verifiable credentials formats utilize 
>> holder binding for reply detection. The public key mentioned above is part 
>> of the cryptographic holder binding that only the legitimate user is able to 
>> execute.
>> 
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>> tokens (those could be short lived) that effectively are verifiable 
>> presentations (based on a verifiable credential) audience restricted for a 
>> certain RS. The client wouldn’t even know it’s a verifiable presentation 
>> since the access token is opaque to the client.
>> 
>>> 
>>> 
>>>> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda 
>>>>  wrote:
>>>> I support adoption.
>>>> 
>>>>  
>>>> 
>>>> To add some color.
>>>> 
>>>>  
>>>> 
>>>> One of the use-cases is a flow where issuance of a user credential 
>>>> (collection of user claims) is decoupled from presentation (where both 
>>>> issuance and presentation of a user credential are done using extensions 
>>>> of OAuth flows). The goal of this decoupling is to avoid “issuer call 
>>>> home”, where the user can send a user credential directly to the RP, 
>>>> without RP needing to cont

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 10:35 schrieb Warren Parad 
> :
> 
> 
> Why would we not include those seemingly critical details in the draft then?
> Let's define what a verifiable presentation is (is that already defined 
> somewhere? I didn't see it in the draft)
> Require the JWTs to be signed with a private key from a certificate chain, 
> and include the whole certificate chain in the body. (I don't think there is 
> already a RFC for this, but I could be wrong)
> Let's also talk about this comment:
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>> tokens (those could be short lived) that effectively are verifiable 
>> presentations (based on a verifiable credential) audience restricted for a 
>> certain RS. The client wouldn’t even know it’s a verifiable presentation 
>> since the access token is opaque to the client.
> 
> If the user's wallet acts as the AS issuing tokens, then there is zero need 
> for this draft because we could pass the scopes that relate to the claims 
> directly to the AS, and have the AS return a limited JWT, and we would 
> actually do that every time because:
> we can
> because the tokens have short lifetime
> So that isn't a valid argument, unless there's a reason why the AS wouldn't 
> be able to do this.

Well, how many access tokens have you seen in the wild that only contain an 
access token? I haven’t, any of the carriers some for of user claims, e.g. a 
sub, in most cases some privileges/roles. Please take a look at 
https://www.rfc-editor.org/rfc/rfc9068.html for best current practice.

Using a VC in the way I described means the original AS doesn’t need to be 
involved in the

> 
>> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt 
>>  wrote:
>> 
>> 
>>>> Am 02.08.2022 um 09:53 schrieb Warren Parad 
>>>> :
>>>> 
>>> 
>>> If we are in a offline scenario how does the verifier got ahold of the 
>>> public key associated with the id token?
>> 
>> Why id token? I would assume we are talking about verifiable presentations, 
>> right?
>> 
>> There are a couple of ways to provide the verifier with the public key 
>> needed to verify. The (raw) key could be contained in the credential or the 
>> presentation. If a trust chain is required, a x.509 certificate could serve 
>> the same purpose.
>> 
>> Beside that offline has different facets. In a Point of Sales scenario, even 
>> though the wallet would be offline the checkout counter would most likely 
>> have connectivity. That would also allow to resolve the public key on demand.
>> 
>>> 
>>> They would need to be online, that defeats any benefit this could provide.
>>> 
>>> Or what if the token you have expires. Many providers issue tokens only 
>>> good for 1 hour. If that expires, the user has to go through the online 
>>> flow again.
>>> 
>>> Unless we can add some provisions to ensure long lived token validity, I 
>>> think in practice we're cripling the usefulness.
>> 
>> Absolutely. That’s the reason a verifiable credential has a much longer 
>> lifetime simply because the user should be able to use it in a sensible way. 
>> As this makes replay more likely, all verifiable credentials formats utilize 
>> holder binding for reply detection. The public key mentioned above is part 
>> of the cryptographic holder binding that only the legitimate user is able to 
>> execute.
>> 
>> In an OAuth scenario, the user‘s wallet would act as AS and issue access 
>> tokens (those could be short lived) that effectively are verifiable 
>> presentations (based on a verifiable credential) audience restricted for a 
>> certain RS. The client wouldn’t even know it’s a verifiable presentation 
>> since the access token is opaque to the client.
>> 
>>> 
>>> 
>>>> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda 
>>>>  wrote:
>>>> I support adoption.
>>>> 
>>>>  
>>>> 
>>>> To add some color.
>>>> 
>>>>  
>>>> 
>>>> One of the use-cases is a flow where issuance of a user credential 
>>>> (collection of user claims) is decoupled from presentation (where both 
>>>> issuance and presentation of a user credential are done using extensions 
>>>> of OAuth flows). The goal of this decoupling is to avoid “issuer call 
>>>> home”, where the user can send a user credential directly to the RP, 
>>>> without RP needing to contact the Issuer directly. So the motivations are 
>>>> not limited t

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

> Am 02.08.2022 um 09:53 schrieb Warren Parad 
> :
> 
> 
> If we are in a offline scenario how does the verifier got ahold of the public 
> key associated with the id token?

Why id token? I would assume we are talking about verifiable presentations, 
right?

There are a couple of ways to provide the verifier with the public key needed 
to verify. The (raw) key could be contained in the credential or the 
presentation. If a trust chain is required, a x.509 certificate could serve the 
same purpose.

Beside that offline has different facets. In a Point of Sales scenario, even 
though the wallet would be offline the checkout counter would most likely have 
connectivity. That would also allow to resolve the public key on demand.

> 
> They would need to be online, that defeats any benefit this could provide.
> 
> Or what if the token you have expires. Many providers issue tokens only good 
> for 1 hour. If that expires, the user has to go through the online flow again.
> 
> Unless we can add some provisions to ensure long lived token validity, I 
> think in practice we're cripling the usefulness.

Absolutely. That’s the reason a verifiable credential has a much longer 
lifetime simply because the user should be able to use it in a sensible way. As 
this makes replay more likely, all verifiable credentials formats utilize 
holder binding for reply detection. The public key mentioned above is part of 
the cryptographic holder binding that only the legitimate user is able to 
execute.

In an OAuth scenario, the user‘s wallet would act as AS and issue access tokens 
(those could be short lived) that effectively are verifiable presentations 
(based on a verifiable credential) audience restricted for a certain RS. The 
client wouldn’t even know it’s a verifiable presentation since the access token 
is opaque to the client.

> 
> 
>> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda 
>>  wrote:
>> I support adoption.
>> 
>>  
>> 
>> To add some color.
>> 
>>  
>> 
>> One of the use-cases is a flow where issuance of a user credential 
>> (collection of user claims) is decoupled from presentation (where both 
>> issuance and presentation of a user credential are done using extensions of 
>> OAuth flows). The goal of this decoupling is to avoid “issuer call home”, 
>> where the user can send a user credential directly to the RP, without RP 
>> needing to contact the Issuer directly. So the motivations are not limited 
>> to offline scenarios, but are applicable to the scenarios that want to 
>> recreate in the online environment, the user experience of presenting 
>> credentials in-person.
>> 
>>  
>> 
>> Driver’s Licence just happens to be an example familiar to many, and there 
>> is no reason it cannot be a diploma, or an employee card, or a training 
>> certificate, etc. But it is worth highlighting that SD-JWT work becomes 
>> critical if we are to enable ISO-compliant mobile Driver Licences expressed 
>> in JSON to enable online scenarios and make life of the Web developers 
>> easier (as opposed processing data encoded as CBOR and signed as a COSE 
>> message). Selective disclosure is a requirement in many government issued 
>> credentials, while the usage of advanced cryptography is not always 
>> encouraged by the national cybersecurity agencies.
>> 
>>  
>> 
>>  
>> 
>> Regarding an approach where issuer issues multiple JWTs of a same type but 
>> with different subset of claims, it is not an ideal way to do selective 
>> disclosure with JWTs (type as a way to differentiate credential with one 
>> data structure/syntax from another). It complicates implementations that try 
>> to provide RP-U unlinkability (RPs cannot collude to track the user). The 
>> simplest way to achieve unlinkability with JWTs without using advanced 
>> cryptography is to issue multiple credentials of the same type but with 
>> varying use identifiers and enable pairwise identifiers per RP. Now there 
>> are multiple copies of each JWT with subset of claims of the same type. This 
>> greatly complicates presentation of these credentials too – since 
>> credentials are of the same type, now wallet needs to manage the combination 
>> of a subset of claims + pairwise identifier…
>> 
>>  
>> 
>> What if the implementation also wants predicates property, where age_over_XX 
>> boolean is sent instead of a birthdate string? The simplest way to do 
>> predicates with JWTs without using advanced cryptography is to have issuers 
>> to issue multiple age_over_xx booleans so that an appropriate one can be 
>> selectively disclosed to the RP. How many “JWTs with subset of claims” does 
>> the issuer needs to issue to account for all possible age requirements? Note 
>> that it’s not just age_over_21 to start gambling, it’s also age_over_65 to 
>> get pension benefits.
>> 
>>  
>> 
>> Managing the combinatorial explosion of sets of claims in speculatively 
>> issued JWTs, many of which will never be used, seems unwieldy, to say the 
>> least. "A 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Torsten Lodderstedt]

+1

> Am 29.07.2022 um 03:13 schrieb Brian Campbell 
> :
> 
> 
> I support adoption.
> 
>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef  
>> wrote:
>> All,
>> 
>> This is a call for adoption for the SD-JWT document
>> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
>> 
>> Please, provide your feedback on the mailing list by August 12th.
>> 
>> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Torsten Lodderstedt]

> Am 19.07.2022 um 18:23 schrieb Brian Campbell :
> 
> The correction is attempting to remove some potential ambiguity that has been 
> interpreted as JAR's requirement for "client_id" not being applicable in the 
> context JAR over PAR. 

I unterstand.If it has caused confusion already, we should change the text.  

>  
> Maybe it should have been an editorial errata rather than technical.
> 
> On Tue, Jul 19, 2022 at 7:44 AM Torsten Lodderstedt  <mailto:tors...@lodderstedt.net>> wrote:
> I’m not sure this requires an update. It basically says „stick the uri you 
> get from step 1 into this parameter in step 2“. Does this really require use 
> to re-state any further requirements of a proper JAR?
> 
>> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef > <mailto:rifaat.s.i...@gmail.com>>:
>> 
>> + Roman and Paul
>> 
>> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell > <mailto:bcampb...@pingidentity.com>> wrote:
>> I believe this should be verified. I'm also the one that reported it though. 
>> But it's been sitting in reported status for a while now. 
>> 
>> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System > <mailto:rfc-edi...@rfc-editor.org>> wrote:
>> The following errata report has been submitted for RFC9126,
>> "OAuth 2.0 Pushed Authorization Requests".
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6711 
>> <https://www.rfc-editor.org/errata/eid6711>
>> 
>> --
>> Type: Technical
>> Reported by: Brian Campbell > <mailto:bcampb...@pingidentity.com>>
>> 
>> Section: 3.
>> 
>> Original Text
>> -
>>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>>to push a Request Object JWT to the authorization server.  The rules
>>for processing, signing, and encryption of the Request Object as
>>defined in JAR [RFC9101] apply.  Request parameters required by a
>>given client authentication method are included in the "application/
>>x-www-form-urlencoded" request directly and are the only parameters
>>other than "request" in the form body (e.g., mutual TLS client
>>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>>while JWT assertion-based client authentication [RFC7523] uses
>>"client_assertion" and "client_assertion_type").  All other request
>>parameters, i.e., those pertaining to the authorization request
>>itself, MUST appear as claims of the JWT representing the
>>authorization request.
>> 
>> Corrected Text
>> --
>>   Clients MAY use the request and client_id parameters as defined in 
>>   JAR [RFC9101] to push a Request Object JWT to the authorization 
>>   server. The rules for processing, signing, and encryption of the 
>>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>>   required by a given client authentication method are included in the
>>   application/x-www-form-urlencoded request directly and are the only 
>>   parameters other than request and client_id in the form body (e.g.,
>>   JWT assertion-based client authentication [RFC7523] uses 
>>   "client_assertion" and "client_assertion_type") HTTP request
>>   parameters). All authorization request parameters, i.e., those 
>>   pertaining to the authorization request itself, MUST appear as
>>   claims of the JWT representing the authorization request.
>> 
>> Notes
>> -
>> That first paragraph of Sec 3 was not properly updated to come inline with 
>> JAR (now RFC9101) when it changed in draft -21 to require "client_id" in the 
>> authorization request in addition to in addition to "request" or 
>> "request_uri" - so is  somewhat ambiguous in maybe suggesting that 
>> "client_id" isn't required. But it is required based on how PAR works and 
>> RFC9101 requiring "client_id".
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC9126 (draft-ietf-oauth-par-10)
>> -

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

[Torsten Lodderstedt]

I’m not sure this requires an update. It basically says „stick the uri you get 
from step 1 into this parameter in step 2“. Does this really require use to 
re-state any further requirements of a proper JAR?

> Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef :
> 
> + Roman and Paul
> 
> On Mon, Jul 18, 2022 at 12:25 PM Brian Campbell  > wrote:
> I believe this should be verified. I'm also the one that reported it though. 
> But it's been sitting in reported status for a while now. 
> 
> On Fri, Oct 15, 2021 at 1:38 PM RFC Errata System  > wrote:
> The following errata report has been submitted for RFC9126,
> "OAuth 2.0 Pushed Authorization Requests".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6711 
> 
> 
> --
> Type: Technical
> Reported by: Brian Campbell  >
> 
> Section: 3.
> 
> Original Text
> -
>Clients MAY use the "request" parameter as defined in JAR [RFC9101]
>to push a Request Object JWT to the authorization server.  The rules
>for processing, signing, and encryption of the Request Object as
>defined in JAR [RFC9101] apply.  Request parameters required by a
>given client authentication method are included in the "application/
>x-www-form-urlencoded" request directly and are the only parameters
>other than "request" in the form body (e.g., mutual TLS client
>authentication [RFC8705] uses the "client_id" HTTP request parameter,
>while JWT assertion-based client authentication [RFC7523] uses
>"client_assertion" and "client_assertion_type").  All other request
>parameters, i.e., those pertaining to the authorization request
>itself, MUST appear as claims of the JWT representing the
>authorization request.
> 
> Corrected Text
> --
>   Clients MAY use the request and client_id parameters as defined in 
>   JAR [RFC9101] to push a Request Object JWT to the authorization 
>   server. The rules for processing, signing, and encryption of the 
>   Request Object as defined in JAR [RFC9101] apply. Request parameters
>   required by a given client authentication method are included in the
>   application/x-www-form-urlencoded request directly and are the only 
>   parameters other than request and client_id in the form body (e.g.,
>   JWT assertion-based client authentication [RFC7523] uses 
>   "client_assertion" and "client_assertion_type") HTTP request
>   parameters). All authorization request parameters, i.e., those 
>   pertaining to the authorization request itself, MUST appear as
>   claims of the JWT representing the authorization request.
> 
> Notes
> -
> That first paragraph of Sec 3 was not properly updated to come inline with 
> JAR (now RFC9101) when it changed in draft -21 to require "client_id" in the 
> authorization request in addition to in addition to "request" or 
> "request_uri" - so is  somewhat ambiguous in maybe suggesting that 
> "client_id" isn't required. But it is required based on how PAR works and 
> RFC9101 requiring "client_id".
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC9126 (draft-ietf-oauth-par-10)
> --
> Title   : OAuth 2.0 Pushed Authorization Requests
> Publication Date: September 2021
> Author(s)   : T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. 
> Skokan
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> 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 2.0 Rich Authorization Requests (RAR): Implementation Status

[Torsten Lodderstedt]

Hi, 

the yes ecosystem (1200 IDPs) uses RAR for authorising payment initiation and 
qualified electronic signatures. 

The Cloud Signature Consortium included RAR as means to authorise electronic 
signature to the v 2.0 of its API for remote signature creation 
(https://cloudsignatureconsortium.org/resources/ 
). 

OpenID Foundation’s FAPI working group added RAR support to the FAPI 2 baseline 
profile (https://openid.net/specs/fapi-2_0-baseline-01.html 
).

best regards,
Torsten. 

> Am 06.04.2022 um 15:46 schrieb Hannes Tschofenig :
> 
> Hi all, 
>  
> I am working on the shepherd writeup for the RAR document and the IESG is 
> interested to hear about the implementation status of this specification.
>  
> What implementations are available that use the RAR functionality or are 
> vendors planning to implement this specification?
>  
> Ciao
> Hannes
>  
> 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

Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Rich Authorization Requests

[Torsten Lodderstedt]

I am not aware of any IPR that pertains to this specification.

> Am 06.04.2022 um 15:34 schrieb Hannes Tschofenig :
> 
> Authors,
>  
> as part of the shepherd write-up, all authors of draft-ietf-oauth-rar must 
> confirm
> that any and all appropriate IPR disclosures required for full conformance
> with the provisions of BCP 78 and BCP 79 have already been filed.
>  
> Please, reply to this email on the mailing list and indicate if you are
> aware of any IPRs associated with this document.
>  
> Ciao
> Hannes
> 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

Re: [OAUTH-WG] WGLC for DPoP Document

[Torsten Lodderstedt]

I support publication of this specification. 

> Am 30.03.2022 um 09:18 schrieb Steinar Noem :
> 
> I support publication of the specification
> 
> ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge  >:
> I support publication of the specification
> 
> On Wed, 30 Mar 2022 at 08:55, Daniel Fett  > wrote:
> I also support publication.
> 
> -Daniel
> 
> Am 29.03.22 um 23:20 schrieb David Waite:
>> I also support publication of this specification
>> 
>> -DW
>> 
>>> On Mar 29, 2022, at 3:12 PM, Mike Jones 
>>> >> > wrote:
>>> 
>>> I support publication of the specification.
>>>  
>>>-- Mike
>>>  
>>> From: OAuth mailto:oauth-boun...@ietf.org>> On 
>>> Behalf Of Rifaat Shekh-Yusef
>>> Sent: Monday, March 28, 2022 5:01 AM
>>> To: oauth mailto:oauth@ietf.org>>
>>> Subject: [OAUTH-WG] WGLC for DPoP Document
>>>  
>>> All,
>>> 
>>> As discussed during the IETF meeting in Vienna last week, this is a WG Last 
>>> Call for the DPoP document:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ 
>>> 
>>> 
>>> Please, provide your feedback on the mailing list by April 11th.
>>> 
>>> Regards,
>>>  Rifaat & Hannes
>>>  
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
> -- 
> https://danielfett.de 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 
> -- 
> Dave Tonge
> CTO
>  
> 
> t: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
> Limited which is authorised and regulated by the Financial Conduct Authority 
> ("FCA"). Moneyhub Financial Technology is entered on the Financial Services 
> Register (FRN 809360) at fca.org.uk/register . 
> Moneyhub Financial Technology is registered in England & Wales, company 
> registration number  06909772 .
> Moneyhub Financial Technology Limited 2018 ©
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, 
> and the information in it is confidential. Use of this email or of any 
> information in it other than by the addressee is unauthorised and unlawful. 
> Whilst reasonable efforts are made to ensure that any attachments are 
> virus-free, it is the recipient's sole responsibility to scan all attachments 
> for viruses. All calls and emails to and from this company may be monitored 
> and recorded for legitimate purposes relating to this company's business. Any 
> opinions expressed in this email (or in any attachments) are those of the 
> author and do not necessarily represent the opinions of Moneyhub Financial 
> Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
> Limited which is authorised and regulated by the Financial Conduct Authority 
> ("FCA"). Moneyhub Financial Technology is entered on the Financial Services 
> Register (FRN 809360) at https://register.fca.org.uk/ 
> . Moneyhub Financial Technology is registered 
> in England & Wales, company registration number 06909772. Moneyhub Financial 
> Technology Limited 2022 © Moneyhub Enterprise, 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, 
> and the information in it is confidential. Use of this email or of any 
> information in it other than by the addressee is unauthorised and unlawful. 
> Whilst reasonable efforts are made to ensure that any attachments are 
> virus-free, it is the recipient's sole responsibility to scan all attachments 
> for viruses. All calls and emails to and from this company may be monitored 
> and recorded for legitimate purposes relating to this company's business. Any 
> opinions expressed in this email (or in any attachments) are those of the 
> author and do not necessarily represent the opinions of Moneyhub Financial 
> Technology Limited or of any other group company.
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 
> -- 
> Vennlig hilsen
> 
> Steinar Noem
> Partner Udelt AS
> 

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

[Torsten Lodderstedt]

I support publication. 

> On 24. Feb 2022, at 17:45, John Bradley  wrote:
> 
> I support publication. 
> 
> -- Original Message --
> From: "Rifaat Shekh-Yusef"  >
> To: "oauth" mailto:oauth@ietf.org>>
> Sent: 2/21/2022 10:12:00 AM
> Subject: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document
> 
>> All,
>> 
>> Mike and Kristina made the necessary changes to address all the great 
>> comments received during the initial WGLC.
>> 
>> This is a second WG Last Call for this document to make sure that the WG has 
>> a chance to review these changes:
>> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html 
>> 
>> 
>> Please, provide your feedback on the mailing list by March 7th.
>> 
>> Regards,
>>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] draft-ietf-oauth-rar-08 review

[Torsten Lodderstedt]

Hi Hannes, 

> Am 21.12.2021 um 13:06 schrieb Hannes Tschofenig :
> 
> Hi all, 
>  
> thanks for writing this document. I have read through it as part of my 
> shepherd writeup and here are a few comments and questions. 

thank you very much for your thorough review. We have tried to incorporate your 
comments and suggestions into revision -09 I just published. 

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-09.html

>  
> Generic Comments:
>  
> As a style issue, it would be good to treat code segments as figures with a 
> figure headings so that references in the text is easier to manage.

Added figure headings to all examples.

>  
> Editorial: s/This draft/This specification

changed 

>  
> Normative language: If you search for MUSTs in the document you will notice 
> two things: First, they are not necessarily where you would expect them.
>  
> For example: This is from page 6, which explains an example.
>  
> "
>The JSON objects with type fields of account_information and
>payment_initiation represent the different authorization data to be
>used by the AS to ask for consent and MUST subsequently also be made
>available to the respective resource servers. 
> "  

Very good catch. The last part of the sentence is intended as a note and not 
normative language whereas the following sentence (not shown) represents a 
normative requirement. I moved the last sentence up to the beginning of this 
section and turned the „MUST subsequently also be made
   available to the respective resource servers.“ into a note. 

"Note: The AS will make this data subsequently available to the respective 
resource servers (see Section 9)."

>  
> Another example from page 29: Here are two approaches offered to mitigate a 
> specific threat. If there are two ways then a MUST is appropriate IMHO. If 
> there are others, maybe it is useful to tell the reader that there are other 
> approaches and when to use those mitigations so that a developer can make an 
> informed decision.
>  
> "
> In order to ensure their integrity, the
>client SHOULD send authorization details in a signed request object
>as defined in [I-D.ietf-oauth-jwsreq] or use the request_uri
>authorization request parameter as defined in [I-D.ietf-oauth-jwsreq]
>in conjunction with [I-D.ietf-oauth-par] to pass the URI of the
>request object to the authorization server.
> "   

The intention of the SHOULD is to recommend clients to ensure the request 
integrity but leave application the room to decide to not care (which is inline 
with OAuth 20 and 2.1).

I suggest the following change

"If integrity of the 
authorization details is a concern, clients MUST protect authorization details 
against tampering and swapping. This can be achieved by signing the request 
using signed request objects as defined in [@I-D.ietf-oauth-jwsreq] or using 
the `request_uri` authorization request parameter as defined in 
[@I-D.ietf-oauth-jwsreq] in conjunction with [@I-D.ietf-oauth-par] to pass the 
URI of the request object to the authorization server."

>  
> Second, several MUST/SHOULD/MAYs are used with little guidance for the 
> developer. Help developers to make the best decision.
>  
> For example: 
> "
>Implementers MUST design and use authorization details in a privacy-
>preserving manner.

The explanation is given in the following paragraphs. We could also remove the 
whole sentence since it states the obvious (in a privacy considerations 
section). 

>
>The AS MUST take into consideration the privacy implications when
>sharing authorization details with the client or resource servers.

We give the advice to share on a „need to know“ basis. I don’t know what else 
we can state. Any ideas?


> "
>  
> In the rest of the review I will go through the individual sections and share 
> my impressions.
>  
>  
> Abstract
>  
> The abstract says: 
>  
> "
>This document specifies a new parameter authorization_details that is
>used to carry fine-grained authorization data in the OAuth
>authorization request.
> "
>  
> Later in the draft we will learn that the authorization_details parameter is 
> not just carried in the authorization request but also in the token request.
>  
> Maybe you could say:
>  
> "
>This document specifies a new parameter authorization_details that is
>used to carry fine-grained authorization data in OAuth
>messages.
> "

Good catch. That was a relict from the time where authorization details were 
sent in the author request only. Adopted text you proposed.

>  
> Section 1: Introduction
>  
> References to blog posts about the motivation for why this work is needed 
> might be better replaced with a short summary, particularly if they motivate 
> the solution in the document. If you don't want such a summary in the body of 
> the document, then the appendix might also be a good place. 

The short summary is given in the introduction. 

The reference to the blog post 

Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

[Torsten Lodderstedt]

I support adoption.

> Am 14.01.2022 um 17:36 schrieb Mike Jones 
> :
> 
> 
> I support adoption.  This specification solves the need for having a key 
> identifier that is also a URI.
>  
>-- Mike
>  
> From: OAuth  On Behalf Of Rifaat Shekh-Yusef
> Sent: Thursday, January 13, 2022 6:27 AM
> To: oauth 
> Subject: [EXTERNAL] [OAUTH-WG] Call for adoption - JWK Thumbprint URI
>  
> All,
> 
> This is a call for adoption for the JWK Thumbprint URI draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/
> 
> Please, provide your feedback on the mailing list by Jan 27th.
> 
> Regards,
>  Rifaat & Hannes
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

[Torsten Lodderstedt]

I think there are two options:
1) validation of the organization/person behind a certain client in order to be 
able to go after them in case of abuse 
2) don’t redirect in an error condition

However, even a successful OAuth process can result in a phishing attack. So I 
don‘t think (2) will help entirely.

Treating OAuth authorization links as phishing attempts sounds reasonable to me.

> Am 18.12.2021 um 16:25 schrieb Warren Parad 
> :
> 
> 
> I also 100% with the recommendation for phishing detectors treat all 
> perceived OAuth links as malicious in emails. It actually isn't hard to know 
> that there is a link embedded in a url query parameter. So I would just take 
> the next step of treating all urls with urls as query parameters as malicious.
> 
> There are exactly zero reasons why a site can't use it's own javascript 
> redirection unless it's domain has been marked as malicious. The only 
> conceivable reason is a third party is providing tracking as a service, and 
> then that's even a better reason to potentially block these.
> 
> Phishing can still use PKCE and PAR, nor does WebAuthN provide protection 
> from this problem.
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress.
> 
> 
>> On Sat, Dec 18, 2021 at 4:11 PM George Fletcher 
>>  wrote:
>> Given the attack is based on a successfully registered callback URL that 
>> is malicious, we can also look to the Authorization Server to run more 
>> checks on the registered callback URLs (e.g. check against the "unsafe" 
>> URL list). Not a 100% solution by any means but could help with reduce 
>> the impact. Additionally, making sure the AS can easily revoke any 
>> client_id and have that take effect quickly.
>> 
>> Another potential option would be to not allow prompt=none (or automatic 
>> redirects) from contexts where the user hasn't first gone through a full 
>> authentication flow or at least allow the AS to display UI at it's 
>> discretion. Though this will definitely break some flows :(
>> 
>> This at least illuminates one of the dangers of allowing a wide open 
>> dynamic client registration model :)
>> 
>> Thanks,
>> George
>> 
>> On 12/18/21 1:11 AM, David Waite wrote:
>> >
>> >> On Dec 17, 2021, at 2:44 PM, Brian Campbell 
>> >>  wrote:
>> >>
>> >> Relax how aggressively OAuth demands that the AS automatically redirect 
>> >> in error conditions. And either respond with a 400 directly (which just 
>> >> stops things at that point) or provide a meaningful interstitial page to 
>> >> the user before redirecting them (which at least helps users see 
>> >> something is amiss). I do think OAuth is a bit overzealous in 
>> >> automatically returning the user's browser context to the client in error 
>> >> conditions. There are some situations (like prompt=none) that rely on the 
>> >> behavior but in most cases it isn't necessary or helpful and can be 
>> >> problematic.
>> > The problem is that if prompt=none still requires redirection without 
>> > prompt or interstitial, someone wishing to treat dynamic registrations of 
>> > malicious sites as clients will just start using prompt=none. Likewise, a 
>> > site could still attempt to manipulate the user to release information by 
>> > imitating an extension to the authentication process, such as an "expired 
>> > password change" prompt.
>> >
>> > I agree with Nov Matake's comment - phishing link email filters should 
>> > treat all OAuth URLs as suspect, as OAuth has several security-recommended 
>> > features like state and PKCE which do not work as expected/reliably with 
>> > email. Filters integrated into the browser (such as based on the unsafe 
>> > site list in Chrome) should not need changes, as they will warn on 
>> > redirect to the known malicious site.
>> >
>> > We should also continue to push as an industry for authentication 
>> > technologies like WebAuthn (as well as mutual TLS and Kerberos) which are 
>> > phishing resistant. We are really talking about failure of a single 
>> > phishing mitigation for _known_ malicious sites - the opportunity to use 
>> > any unknown malicious site or a compromised legitimate site remains open 
>> > even if we do suggest changes to error behavior.
>> >
>> > -DW
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> 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-WG] GAIN Digital Trust

[Torsten Lodderstedt]

Hi all, 

as requested in the OAuth office hour yesterday, I would like to share a link 
to the GAIN site.

At https://gainforum.org/  you can find the whitepaper 
written by more than 150 experts suggesting to built a global network of 
identity providers. The network shall be open to anyone able to provide assured 
identity data. The envisioned architecture follows the patterns established by 
open banking, i.e. every service provider can offer its services directly to 
relying parties via a standardized, interoperable API. The network will 
facilitate discovery and trust among the parties.

In the next step, we want to build a Proof of Concept to evaluate and 
demonstrate the feasibility of the approach. 

If you want to know more or want to contribute just drop me an email. 

best regards,
Torsten. ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi all,

we published a new revision -07 containing the following changes:

• removed use of resource indicators to filter authorization details in 
token response (to simplify spec)
• incorporated review feedback from WGLC
• fixed wording in token introspection section
• added privacy considerations re authorization details in token 
response

Thanks to all the reviewers!

best regards,
Torsten. 

> Am 12.09.2021 um 17:31 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 Rich Authorization Requests
>    Authors     : Torsten Lodderstedt
>  Justin Richer
>  Brian Campbell
>   Filename: draft-ietf-oauth-rar-07.txt
>   Pages   : 41
>   Date: 2021-09-12
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine-grained authorization data in the OAuth
>   authorization request.
> 
> 
> The IETF datatracker status page for this draft is:
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/=gmail-imap=163206556200=AOvVaw2mNxPXxbjUclgOYKnqcoWm
> 
> There is also an HTML version available at:
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-07.html=gmail-imap=163206556200=AOvVaw3H8e6Las-aD9X70yWaIawL
> 
> A diff from the previous version is available at:
> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-07=gmail-imap=163206556200=AOvVaw1KAg4Yy6K3TChmooA2YVmP
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=163206556200=AOvVaw1w7aPQ263YvHjFUJZZQq8r

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

Re: [OAUTH-WG] OAuth Interim Meetings

[Torsten Lodderstedt]

Hi,

we would like to give an update on RAR.

best regards,
Torsten.

> Am 05.09.2021 um 05:19 schrieb Aaron Parecki :
> 
> I would like to present on OAuth 2.1.
> 
> Separately, and preferably later in the series, I would like to present on 
> the Browser App BCP.
> 
> Thanks!
> 
> Aaron
> 
> 
> 
> On Sat, Sep 4, 2021 at 8:23 AM Rifaat Shekh-Yusef  > wrote:
> All,
> 
> We would like to start a new series of interim meetings later in September.
> Please, let us know if you would like to present during one of these meetings.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> -- 
> ---
> Aaron Parecki
> https://aaronparecki.com 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=163141679900=AOvVaw0Tjp5Vv2d_eaYA42SVFIeu

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

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

[Torsten Lodderstedt]

Hi Jacob, 

and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 
<https://github.com/oauthstuff/draft-oauth-rar/pull/79> for review. 

Thanks for the proposed text. I modified it a bit because I think the AS should 
only omit data (not mask) and data can be provided even if considered sensitive 
as long as there is a reasonable purpose and a legal basis. 

best regards,
Torsten. 

> Am 06.09.2021 um 09:52 schrieb Jacob Ideskog :
> 
> Yes, privacy considerations could be more explicit about this. It should 
> probably explicitly mention the token response and the Client.
> 
> I also suggest clarifying in 7 or 7.1 that the token response MAY be less 
> explicit or even different than the authorization details issued in the 
> tokens.
> 
> This is not simple, since it may lead the Client to think it has more (or 
> less) access than it actually does, but since the intended audience of the 
> authorized data is the RS it should be ok.
> A scenario I see is that the client requests Account access based on 
> pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The AS 
> replaces these with the actual account numbers ("accounts" : ["123-123", 
> "234-BCD"]) so the RS doesn't have
> to deal with those translations. So: in the token response the pseudonyms are 
> still used, but in the issued token the explicit account values are used.
> 
> Suggestion for  section 7:
> "The AS MAY omit, mask or hide values in the authorization_details to the 
> Client in the Token Response if these are deemed sensitive and of no intended 
> use for the Client."
> 
> Something in that direction would make it more clear that it is allowed to do 
> so, and that the Token Response doesn't prevent the issued token from 
> containing sensitive data.
> 
> /Jacob
> 
> 
> Den lör 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>>:
> The AS intentionally shares the list of accounts in the mentioned example 
> with the client. The assumption is the client asks for access to some 
> accounts and the user decides which accounts to grant the client access to. 
> This means the AS is authorized by the user to share this data.
> 
> The privacy considerations section already has text about sharing data with 
> resource servers. I suggest to add some text re data sharing with clients.
> 
> Would that work for you?
> 
> > Am 04.09.2021 um 03:12 schrieb Justin Richer  > <mailto:jric...@mit.edu>>:
> > 
> > This is a fair point... The privacy and security considerations talk about 
> > this a bit as I recall, but likely need to in more depth and specificity. 
> > This is an intentional message channel to the client from the AS, but if 
> > the AS is blindly sending all information it might be saying more than it 
> > means to say to an entity that doesn't need that detail to function. Scopes 
> > have similar issues, but this structure adds more opportunities for 
> > mistakes just due to the possible increased complexity. 
> > 
> > -Justin
> > 
> > From: OAuth [oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] on 
> > behalf of Jacob Ideskog [jacob.ides...@curity.io 
> > <mailto:jacob.ides...@curity.io>]
> > Sent: Friday, September 3, 2021 10:42 AM
> > To: oauth
> > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in 
> > draft-ietf-oauth-rar-05
> > 
> > Hi all,
> > 
> > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that 
> > describes the token response.
> > 
> > The authorization_details values could be sensitive in their nature. The 
> > example in section 7.1 highlights this nicely. The accounts array is empty 
> > when the client requests it, but is enriched by the AS and returned to the 
> > client in the token response.
> > 
> > This means that the AS may leak potentially sensitive information to the 
> > client in a new place. Before this was only possible in the ID Token or 
> > UserInfo or if the AS returned a JWT as an access token which the client 
> > popped open (even though it shouldn't).
> > 
> > I understand that the spec considers this an option for the AS to enrich or 
> > not. I think the enrichment is good and necessary, but with the side-effect 
> > of it ending up in the token response it becomes an issue.
> > 
> > Is the token response a mirror of the authorization_details claim in the 
> > corresponding access token, or can it be a masked version?
> > 
> > Perhaps the security co

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

[Torsten Lodderstedt]

The AS intentionally shares the list of accounts in the mentioned example with 
the client. The assumption is the client asks for access to some accounts and 
the user decides which accounts to grant the client access to. This means the 
AS is authorized by the user to share this data.

The privacy considerations section already has text about sharing data with 
resource servers. I suggest to add some text re data sharing with clients.

Would that work for you?

> Am 04.09.2021 um 03:12 schrieb Justin Richer :
> 
> This is a fair point... The privacy and security considerations talk about 
> this a bit as I recall, but likely need to in more depth and specificity. 
> This is an intentional message channel to the client from the AS, but if the 
> AS is blindly sending all information it might be saying more than it means 
> to say to an entity that doesn't need that detail to function. Scopes have 
> similar issues, but this structure adds more opportunities for mistakes just 
> due to the possible increased complexity. 
> 
> -Justin
> 
> From: OAuth [oauth-boun...@ietf.org] on behalf of Jacob Ideskog 
> [jacob.ides...@curity.io]
> Sent: Friday, September 3, 2021 10:42 AM
> To: oauth
> Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in 
> draft-ietf-oauth-rar-05
> 
> Hi all,
> 
> I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that 
> describes the token response.
> 
> The authorization_details values could be sensitive in their nature. The 
> example in section 7.1 highlights this nicely. The accounts array is empty 
> when the client requests it, but is enriched by the AS and returned to the 
> client in the token response.
> 
> This means that the AS may leak potentially sensitive information to the 
> client in a new place. Before this was only possible in the ID Token or 
> UserInfo or if the AS returned a JWT as an access token which the client 
> popped open (even though it shouldn't).
> 
> I understand that the spec considers this an option for the AS to enrich or 
> not. I think the enrichment is good and necessary, but with the side-effect 
> of it ending up in the token response it becomes an issue.
> 
> Is the token response a mirror of the authorization_details claim in the 
> corresponding access token, or can it be a masked version?
> 
> Perhaps the security considerations section should be updated with a 
> statement with regards to the fact that the client may see claim data only 
> intended for the RS?
> 
> Regards
> Jacob Ideskog
> 
> 
> 
> --
> Jacob Ideskog
> CTO
> Curity AB
> ---
> Sankt Göransgatan 66, Stockholm, Sweden
> M: +46 70-2233664
> ja...@curity.io
> curity.io
> ---
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=163132276000=AOvVaw2Fa1GyOiE6a7mRCghwMI5J


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

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

[Torsten Lodderstedt]

Hi Ash,

> Am 31.08.2021 um 02:42 schrieb Ash Narayanan :
> 
> Hi Dick,
> 
> >The access token represents the authorization to access the resource(s) --
> >it does not represent the authorization to manipulate tokens. 
> 
> Anything for which the client must have an access token to access is a 
> protected resource. In order to revoke a token, the client must have the 
> associated access token to begin with, hence a protected resource. If not a 
> protected resource, it is implied anyone can access it, and the OAuth spec 
> makes no assertions about where a protected resource must be located so 
> there's no reason it can't be on the AS as well.
> 
> Emond describes it quite neatly:
> >> I see it like returning a key when you no longer need access to a 
> >> building. 
> >> The fact that you hold the key should be enough for you to be able to 
> >> return it.
> 
> So you shouldn't be returning a key you never had.
> 
> Anything for which you may use a client_secret if you have one or not if you 
> don't is generally a red flag. In RFC 7009 as I've pointed out, the client_id 
> is being used as a security measure as it's part of the authentication 
> header. Furthermore, it also mentions an attacker guessing it (in addition to 
> the token). The client_id is by no means a secure item on a non-confidential 
> client such as an SPA.
> 
> Also you say:
> > Changing the spec would change the security assumptions that existing 
> > deployments have made.
> 
> Isn't that the nature of the business? Or are you implying that no deployment 
> should ever change even if improvements are found?

Certainly not. However, an errata is not supposed to change the security 
assumptions of a spec. It is supposed to fix typos and clarify ambiguities. 
Changing the security assumptions or applying other normative changes is 
subject to new RFCs replacing the older ones. 

So from my perspective, your inquiry exceeds the scope of an errata. 

best regards,
Torsten. 

> 
> Ash
> 
> 
> >Hey Emond
> >
> >The access token represents the authorization to access the resource(s) --
> >it does not represent the authorization to manipulate tokens. The client
> >credentials are used for token management. While your implementation may be
> >ok with using the access token to revoke itself, it is not the security
> >model represented by the specification. Changing the spec would change the
> >security assumptions that existing deployments have made.
> >
> >As noted in your response, the CLI has access to the client credentials to
> >revoke. Besides convenience, it is not clear to me why you would not want
> >to require the client credentials -- but it is your implementation -- you
> >can make your own decisions where and if you want to be compliant.
> >
> >Warren: an interesting idea to provide more context on this in OAuth 2.1.
> >
> >/Dick
> >ᐧ
> >
> >On Tue, Aug 24, 2021 at 8:10 AM Emond Papegaaij  >>
> >wrote:
> >
> >> On Tue, Aug 24, 2021 at 12:14 PM Warren Parad  >> > wrote:
> >>
> >>> I think it is worth pointing out, if we were to agree with the errata,
> >>> that this particular use case probably isn't relevant:
> >>>
> >>> Our client in this case was a command line tool, which only requests the
>  client credentials on login. It then fetches an access token and stores
>  this locally. The client credentials are not stored by default.
> >>>
> >>>
> >>> Unless I misunderstand, I'll take "client credentials" to mean client Id
> >>> and client credentials via a client credentials grant. And therefore, is
> >>> not the correct flow to be used in a command line tool. Client credentials
> >>> are used in private when there are many user agents that could connect
> >>> through it, I would not recommend this as the solution here, and even if 
> >>> it
> >>> were, you would indeed have access to the client id and secret, so it 
> >>> would
> >>> not be a problem to use them to revoke the token.
> >>>
> >>
> >> The CLI-tool actually supports both a 3-legged (via the device
> >> authorization grant) and a 2-legged flow (via the client credentials
> >> grant). It depends on the use case which one is appropriate. In the case of
> >> a user logging in to access the application via the CLI, it clearly is the
> >> 3-legged flow, however when the CLI is used in a script that runs without
> >> user interaction, it's the 2-legged flow. In this later case, the script
> >> often fetches the credentials from some store, uses them to acquire an
> >> access token, does it job, and revokes the token. Naturally, it can fetch
> >> the credentials a second time to revoke the token, but I really don't see
> >> the point in this case. The client merely indicates it is done with the
> >> token and it can now be revoked. It is good practice to discard any
> >> credentials when you are done with them to minimize the chance of abuse.
> >> However, requiring the client authentication to revoke the 

Re: [OAUTH-WG] RAR WGLC comment

[Torsten Lodderstedt]

Hi all,

I created a PR for this change. 

https://github.com/oauthstuff/draft-oauth-rar/pull/76 
<https://github.com/oauthstuff/draft-oauth-rar/pull/76>

Please review and comment/approve. 

best regards,
Torsten. 

> Am 19.06.2021 um 17:01 schrieb Filip Skokan :
> 
> I support such change.
> 
> Odesláno z iPhonu
> 
>> 19. 6. 2021 v 15:36, Torsten Lodderstedt 
>> :
>> 
>> 
>> Hi Brian,
>> 
>> the idea was to use resource indicators as convenient short cut to support 
>> audience restricted access tokens. However, I agree this can be achieved by 
>> specifying authorization details in the token request as well.
>> 
>> So I‘m fine with dropping resource indicators for RAR at all. This means RAR 
>> on one hand and scopes + resource indicators on the other hand are clearly 
>> decoupled and independent.
>> 
>> best regards,
>> Torsten.
>> 
>>> Am 18.06.2021 um 20:13 schrieb Brian Campbell 
>>> :
>>> 
>>> 
>>> In my reading and understanding of the text and intent, the content and 
>>> meaning of a particular authorization details object are fully governed by 
>>> its "type". And while the draft provides a set of common data elements 
>>> intended to be usable across different types (locations, actions, 
>>> datatypes, identifier, privileges) a specific type is free to define 
>>> whatever suits its needs. A type definition may or may not involve those 
>>> common elements and could even use the same name(s) with different meaning 
>>> or structure. 
>>> 
>>> So, while I understand the motivation behind the RFC8707 resource parameter 
>>> being usable in a token request to make the AS filter, the included 
>>> authorization details of the resultant token based on the "locations" 
>>> element[1], I'm a bit concerned about a layering problem here. The 
>>> authorization details objects of the grant might not contain a "locations" 
>>> element or might have one with a different meaning or structure.  
>>> 
>>> The draft also describes using the authorization_details token request 
>>> parameter to specify the authorization details a client wants the AS to 
>>> assign to a particular access token[2]. So the problematic resource 
>>> parameter behaviour is also kind of redundant. I think maybe it should be 
>>> removed.
>>> 
>>> [*] described in 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 
>>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523section-6.2%26source%3Dgmail-imap%26ust%3D162464483100%26usg%3DAOvVaw2Neq-jZjDLFKLvk4ORFZgL=gmail-imap=162471972100=AOvVaw3VREfBmTcEdimVCRXcGUpu>
>>>  and mentioned at 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 
>>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523section-1-8%26source%3Dgmail-imap%26ust%3D162464483100%26usg%3DAOvVaw1RV1Hi3T3GesR4hdU-tNIj=gmail-imap=162471972100=AOvVaw3Ccx5Oj2Y6lY4zx0PxUwGH>
>>>  and in 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 
>>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523section-7-1%26source%3Dgmail-imap%26ust%3D162464483100%26usg%3DAOvVaw0ALWuf7bYYCKFQZUkl4NFz=gmail-imap=162471972100=AOvVaw0B5JKz5Tm3oF4SQv0Olywy>
>>> 
>>> [2] 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
>>>  
>>> <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html%2523name-token-request%26source%3Dgmail-imap%26ust%3D162464483100%26usg%3DAOvVaw1rkJogfzl-0dbnMhVtiOwW=gmail-imap=162471972100=AOvVaw3BVO3rOm3nxewYzy1aOVqt>
>>> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162464483100=AOvVaw1Ol8hiDotFufYe9jQCTi1m
>> ___
>> 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] WG Last Call on the RAR Document

[Torsten Lodderstedt]

Dear Dave,

thanks a lot for your review!

I create a PR with the changes you proposed. 

https://github.com/oauthstuff/draft-oauth-rar/pull/75 


Please review and comment/approve. 

> Am 08.06.2021 um 12:33 schrieb Dave Tonge :
> 
> Dear RAR authors
> 
> Thank you for your work on this draft - I believe it will be very helpful to 
> many ecosystems and am in favour of its progression.

Thank you. 

> 
> A few nits:
> 
> Whole Document
>  - "payment initiation" is I think a PSD2 specific term, I'm not sure about 
> its use in the document, perhaps just "payment API" is sufficient? If it is 
> used, perhaps it needs a definition?

I changed the wording and added a short explanation of the term. Please have a 
look.

>  
> Introduction
> - "enables the AS to mint RS-specific" - I wonder whether "mint" is a well 
> enough understood term?

Changed it to „issue"

> 
> Section 2
>  - final example in 2.1 - is the array of authorization details supposed to 
> be under the `resources` key?

Good catch. I assume this is a remaining of the back port from GNAP. Fixed it.

> 
> Section 3
>  - Should PAR be added to 6747,8628 and CIBA in section 3? I know it is 
> referenced in 12.4, but I think that RAR and PAR fit very well together and 
> it would be better to call out earlier on in the spec ( it is mentioned 
> extensively in the security and privacy considerations and so I think 
> therefore should be mentioned earlier)

I added a paragraph including references to the security/privacy/implementation 
considerations.

>  - I suggest that mention is made in section 3 that the RO may grant a subset 
> of the request authorization details. This is mentioned in section 7.1 but I 
> feel it should be addressed in the authorization section. 

I added a note on that.

> 
> Section 7
> The title for section 7.1 could maybe adjusted to simply "Authorization 
> details in Token Response" as it deals with both enrichment and a subset 
> being returned.

Can you please refer to text in 7.1 taking about subsets? 

> In addition I don't think it is clear whether an AS is required to enrich the 
> authorization details. The statement is made
> 
> >  In order to allow the client to determine the
>accounts it is entitled to access, the authorization server will add
>this information to the respective authorization details object.
> 
> However a more standard approach currently is that the Client would simply 
> query an `/accounts` endpoint and would receive accounts to which it has been 
> given access to - without having to know their identifiers up front. There 
> could be a situation where a resource owner grants access to all their 
> accounts (including accounts opened in the future). Having the AS be required 
> to fill in the account identifiers in the token response could be 
> restrictive. I think this kind of enrichment is nice, but I suggest that it 
> be made clear that it is optional.

Rephrased it to clearly point out this is _a_ design option.
> 
> Section 12
>  - typo: "follwowing" -> "following"
> 

fixed. 

best regards,
Torsten. 

> Dave
> 
> 
> 
> 
> On Mon, 7 Jun 2021 at 22:19, Rifaat Shekh-Yusef  > wrote:
> All,
> 
> This is to start a WG Last Call on the RAR document, that ends June 22nd.
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05 
> 
> 
> Please, review the document and provide your feedback on the mailing list. 
> A feedback that states that you have reviewed the document and have no 
> concerns would also be very helpful.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 
> -- 
> Dave Tonge
> CTO
>  
> 
> t: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
> Limited which is authorised and regulated by the Financial Conduct Authority 
> ("FCA"). Moneyhub Financial Technology is entered on the Financial Services 
> Register (FRN 809360) at fca.org.uk/register 
> .
>  Moneyhub Financial Technology is registered in England & Wales, company 
> registration number  06909772 .
> Moneyhub Financial Technology Limited 2018 ©
> 
> DISCLAIMER: This email (including any attachments) is subject 

Re: [OAUTH-WG] RAR WGLC editorial feedback

[Torsten Lodderstedt]

Thanks Brian. Review and approved.

> Am 17.06.2021 um 21:27 schrieb Brian Campbell 
> :
> 
> In a PR to try and make it easy 
> https://github.com/oauthstuff/draft-oauth-rar/pull/74/files#diff-cbb16c6731a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66b
>  
> 
>  
> 
> 
> 
> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162456288400=AOvVaw0FivdKy1B9S-6DJN8kt1jJ

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

Re: [OAUTH-WG] RAR WGLC comment

[Torsten Lodderstedt]

Hi Brian,

the idea was to use resource indicators as convenient short cut to support 
audience restricted access tokens. However, I agree this can be achieved by 
specifying authorization details in the token request as well.

So I‘m fine with dropping resource indicators for RAR at all. This means RAR on 
one hand and scopes + resource indicators on the other hand are clearly 
decoupled and independent.

best regards,
Torsten.

> Am 18.06.2021 um 20:13 schrieb Brian Campbell 
> :
> 
> 
> In my reading and understanding of the text and intent, the content and 
> meaning of a particular authorization details object are fully governed by 
> its "type". And while the draft provides a set of common data elements 
> intended to be usable across different types (locations, actions, datatypes, 
> identifier, privileges) a specific type is free to define whatever suits its 
> needs. A type definition may or may not involve those common elements and 
> could even use the same name(s) with different meaning or structure. 
> 
> So, while I understand the motivation behind the RFC8707 resource parameter 
> being usable in a token request to make the AS filter, the included 
> authorization details of the resultant token based on the "locations" 
> element[1], I'm a bit concerned about a layering problem here. The 
> authorization details objects of the grant might not contain a "locations" 
> element or might have one with a different meaning or structure.  
> 
> The draft also describes using the authorization_details token request 
> parameter to specify the authorization details a client wants the AS to 
> assign to a particular access token[2]. So the problematic resource parameter 
> behaviour is also kind of redundant. I think maybe it should be removed.
> 
> [*] described in 
> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 and 
> mentioned at 
> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and 
> in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1
> 
> [2] 
> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
> 
> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162464483100=AOvVaw1Ol8hiDotFufYe9jQCTi1m
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Torsten Lodderstedt]

Hi,

> Am 25.05.2021 um 16:59 schrieb A. Rothman :
> 
> Hi,
> 
> In RFC 6749 section 4.1, the Authorization Code Grant flow starts with:
> 
> (A)  The client initiates the flow by directing the resource owner's
> user-agent to the authorization endpoint.  The client includes
> its client identifier, requested scope, local state, and a
> redirection URI to which the authorization server will send the
> user-agent back once access is granted (or denied).
> 
> (B)  The authorization server authenticates the resource owner (via
> the user-agent) and establishes whether the resource owner
> grants or denies the client's access request.
> 
> 
> From this, and most explanation I've seen, I understand that the client (e.g. 
> my web server) is supposed to prepare the Authorization Request URL but 
> instead of sending it to the Authorization Server, it redirects the user 
> agent which is the one actually making the HTTP request. It then goes back 
> and forth with the Authorization Server (with HTML and posting forms and 
> whatnot), and eventually receives the Authorization Response which redirects 
> the user agent back to the client's callback URL with the included code 
> parameter. So as far as the Authorization Request/Response flow goes, there 
> is no direct communications between the client and Authorization Server up to 
> this point (before the token exchange).
> 
> 1. Basically correct so far?

yep. 

> 
> Now, I've encountered a provider that works slightly differently (but still 
> with the Authorization Code Grant scheme): the client (my web server) is 
> supposed to send the Authorization Request directly to the Authorization 
> Server, then receive some opaque URL, and redirect the user agent to there to 
> continue the process. I suppose this URL is equivalent to one from the middle 
> of the 'back and forth' in the previous scenario. The rest of the flow 
> continues the same. So basically, the initial redirect response and HTTP 
> request are reversed - instead of first redirect and then request (from user 
> agent), there is first the request (from client)  and then redirect.
> 
> So the questions are:
> 
> 2. Is this compliant with the RFC?

I don’t think so. 

> 
> 3. Is it any less secure? (even if not strictly compliant with the RFC's 
> flow, it may still be secure...)

Difficult to access without further details. Beside this, I see the service 
provider as being responsible to ensuring it is secure. 

> 
> 4. If it is less secure, what are the possible vulnerabilities or attacks 
> made possible here that are mitigated in the original flow?
> 
> 5. They claim the change is made because they insist on using MTLS on all 
> Authentication Server endpoints, including the Authorization Endpoint. Does 
> this make sense? Does it add security, or is the OAUTH2 flow just as secure 
> without MTLS on the Authorization Endpoint?

I kind of understand the rationale. Sending the authorisation request to the AS 
first (using mTLS) allows the AS to check the client’s identity and permissions 
before the user interaction starts. With a standard redirect (without signed 
request objects), the AS never knows whether request really comes from the 
legit client. This is determined once the code is exchanged at the token 
endpoint (rather late in the process). 

Fo this and other reasons, the OAuth WG has specified the Pushed Authorization 
Requests (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par) extension 
that works similarly. We indeed have done a security analysis of this draft. 

BTW: the communication between user agent and authorisation server is still not 
protected with mTLS in the solution you described ;-).

best regards,
Torsten.  

> 
> Thanks,
> 
> Amichai
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162255960200=AOvVaw3uYa4JD_Cmmp4TyaTR0UqL

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

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-rar-05.txt

[Torsten Lodderstedt]

Hi all, 

we just published a new revision of RAR. 

Here is the list of changes:

added authorization_details token request parameter and discussion on 
authorization details comparison 

added privileges field to authorization details (to align with GNAP) 

added IANA text and changed metadata parameter names 

added text about use of machine-readable type schemas, e.g JSON Schema 

added text on how authorization details are determined for access token issued 
with token response 

added token error response and further error conditions to authorization error 
response


Please give us feedback. 

The draft is now feature complete from the perspective of the authors. So we 
are aiming at asking the chairs to start WGLC. 

best regards,
Torsten. 

> Anfang der weitergeleiteten Nachricht:
> 
> Von: internet-dra...@ietf.org
> Betreff: New Version Notification for draft-ietf-oauth-rar-05.txt
> Datum: 15. Mai 2021 um 20:34:13 MESZ
> An: Brian Campbell , Justin Richer 
> , Torsten Lodderstedt 
> 
> 
> A new version of I-D, draft-ietf-oauth-rar-05.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name: draft-ietf-oauth-rar
> Revision: 05
> Title:OAuth 2.0 Rich Authorization Requests
> Document date:2021-05-15
> Group:oauth
> Pages:43
> URL:
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.txt=gmail-imap=162170845500=AOvVaw3AD80Xsr4FKahwS02BL42V
> Status: 
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/=gmail-imap=162170845500=AOvVaw0QU88gwZS5gDXDrwsKl1Qh
> Html:   
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html=gmail-imap=162170845500=AOvVaw3WCjco3EC1DVEPNMPDls7g
> Htmlized:   
> https://www.google.com/url?q=https://tools.ietf.org/html/draft-ietf-oauth-rar-05=gmail-imap=162170845500=AOvVaw16dhK0NC7iMgY_bSGklxXQ
> Diff:   
> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-05=gmail-imap=162170845500=AOvVaw3d63udnBD3g9cpudz-8SFi
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

[Torsten Lodderstedt]

Hi,

I have read the document and have no concerns.

As an editorial feedback, I would suggest to drop „ If implemented correctly,“ 
in the abstract since this apparently is a prerequisite for all kinds of 
security controls ;-)

best regards,
Torsten.

> Am 01.05.2021 um 22:47 schrieb Rifaat Shekh-Yusef :
> 
> 
> All,
> 
> We have not seen any comments on this document.
> Can you please review the document and provide feedback, or indicate that you 
> have reviewed the document and have no concerns.
> 
> Regards,
>  Rifaat & Hannes
> 
> 
>> On Thu, Apr 15, 2021 at 3:04 AM Karsten Meyer zu Selhausen 
>>  wrote:
>> Hi all,
>> 
>> the latest version of the security BCP references 
>> draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to mix-up attacks.
>> 
>> There have not been any concerns with the first WG draft version so far: 
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
>> 
>> I would like to ask the WG if there are any comments on or concerns with the 
>> current draft version.
>> 
>> Otherwise I hope we can move forward with the next steps and hopefully 
>> finish the draft before/with the security BCP.
>> 
>> Best regards,
>> Karsten
>> 
>> -- 
>> Karsten Meyer zu Selhausen
>> Senior IT Security Consultant
>> Phone:   +49 (0)234 / 54456499
>> Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, 
>> Security Training
>> 
>> Is your OAuth or OpenID Connect client vulnerable to the severe impacts of 
>> mix-up attacks? Learn how to protect your client in our latest blog post on 
>> single sign-on:
>> https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>> 
>> Hackmanit GmbH
>> Universitätsstraße 60 (Exzenterhaus)
>> 44789 Bochum
>> 
>> Registergericht: Amtsgericht Bochum, HRB 14896
>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
>> Christian Mainka, Dr. Marcus Niemietz
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162050684200=AOvVaw3dG-hH8lliyL13KAjSOYwA


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

[OAUTH-WG] authorization_details token request parameter and comparison in RAR

[Torsten Lodderstedt]

Hi all,

in the recent RAR session, we started a discussion about an 
authorization_details token request parameter. 

This parameter would allow us to solve several outstanding topics: 
- Let the client determine what privileges to assign to the first access token 
issued in exchange for an authorisation code
- Downscoping privileges of pre-existing grant (code, refresh token, CIBA, 
device)
- Request access tokens with client credentials  

We also discussed the challenge of comparing requested and already granted 
authorization details and how this relates to the way application/API specific 
logic might be integrated into an AS.

In order to continue the discussion, we would like to share the following PR 
with you for discussion: 

https://github.com/oauthstuff/draft-oauth-rar/pull/66

It introduces the authorization_details token request parameter and gives 
examples of how comparison could be performed in this context. 

Please give us feedback on the PR to drive the discussion. 

best regards,
Torsten.  


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

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: IPR Confirmation

[Torsten Lodderstedt]

Hi Hannes,

I‘m not aware of any IPR related to this draft.

best regards,
Torsten.

Filip Skokan  schrieb am Mi. 24. März 2021 um 21:25:

> Hello Hannes. I am not aware of any IPR related to this document.
>
> Cheers,
> Filip
>
> Odesláno z iPhonu
>
> 24. 3. 2021 v 20:52, Hannes Tschofenig :
>
> 
>
> Hi Torsten, Brian, Nat, Dave, Filip,
>
>
>
> I am working on the shepherd writeup for the "OAuth 2.0 Pushed Authorization 
> Requests"  specification.
>
>
>
> One item in the shepherd template requires me to indicate whether each 
> document author has confirmed that any and all appropriate IPR disclosures 
> required for full conformance with the provisions of BCP 78 and BCP 79 have 
> already been filed.
>
>
>
> Could you please confirm?
>
>
>
> Ciao
>
> Hannes
>
>
> 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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt

[Torsten Lodderstedt]

> Am 13.02.2021 um 00:38 schrieb Brian Campbell 
> :
> 
> 
> 
> On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha 
>  wrote:
> Find bellow my review of the draft:
> 
>   • Redactional changes:
> 2.2.  Authorization Data Types
> 
> Interpretation of the value of the "type" parameter, and the object
>elements that the "type" parameter allows => allowed
> 
> 
> The "allows" seems correct there. 
> 
>  
> 
> 9.  Metadata
> which is an
>JSON array. => which is a JSON array
> 
> Fixed this in the document source. Thanks!
>  
>   • Application to existing APIs
> reason-1: Current open banking initiatives are built on the of existing Data 
> Standards like ISO20022 (PAIN, CAMT) which are XML's that do not provide 
> direct translation to JSON. Some authorization server's might even be able to 
> parse an ISO PAIN file to display the proper authorization request to the 
> user.
> 
> That the APIs are XML doesn't necessarily mean that the details of the 
> authorization can't be represented in JSON. And, if really need be, XML can 
> be included as the value of some member in the authorization details and 
> defined as such by the type. 
> 
>  
> reason-2: In some situation, it might be more privacy preserving to have the 
> authorization request content negotiated between the AS and the RS. In this 
> case the "scope" parameter shall only carry some sort of "grant-id" (known in 
> the Berlin Group spec as consent-id). This will allow the AS to negotiate the 
> data to be displayed directly with the RS.

I think you are referring to different relationships, namely client to AS vs AS 
to RS. 

Authorization details carry the client’s request data (e.g. amount to be 
transferred) to the AS. Whatever the AS wants to negotiate with the RS to be 
displayed by the AS can be negotiated between AS and RS if needed via a 
suitable interface. However, I would assume this negotiation is informed by the 
client’s request data.  So both concepts are complementary in my opinion.  

> 
> RAR probably just isn't applicable in that kind of case. 


 
> 
>  
> 
> Any idea how to consider these two edge cases?
> 
> 
>  
> Best regards.
> /Francis
> 
> 
> From: OAuth  on behalf of Torsten Lodderstedt 
> 
> Sent: Sunday, February 7, 2021 12:49 PM
> To: oauth 
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt
>  
> Hi all,
> 
> here is the list of changes in revision -04:
> 
>   • restructured draft for better readability
>   • simplified normative text about use of the resource parameter with 
> authorization_details 
>   • added implementation considerations for deployments and products
>   • added type union language from GNAP  
>   • added recommendation to use PAR to cope with large requests and for 
> request protection
> 
> Your feedback is highly appreciated.
> 
> best regards,
> Torsten. 
> 
>> Am 07.02.2021 um 13:42 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 Rich Authorization Requests
>>Authors : Torsten Lodderstedt
>>  Justin Richer
>>  Brian Campbell
>> Filename: draft-ietf-oauth-rar-04.txt
>> Pages   : 36
>> Date: 2021-02-07
>> 
>> Abstract:
>>   This document specifies a new parameter "authorization_details" that
>>   is used to carry fine grained authorization data in the OAuth
>>   authorization request.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/=gmail-imap=161330655700=AOvVaw3-4SmuMFgxbz-cDK2Ir_a7
>> 
>> There is also an HTML version available at:
>> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.html=gmail-imap=161330655700=AOvVaw1J52xGTvk1ZAuBC_fUAIjJ
>> 
>> A diff from the previous version is available at:
>> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-04=gmail-imap=161330655700=AOvVaw0TYqmFwryvAYznR2Ho5Oj6
>> 
>> 
>> 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-draf

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Torsten Lodderstedt]

Thank you again for the explanation. 

I think your assumption about the overall flow should be described in the 
draft. 

As I understand it now the core contribution of your proposal is to move 
refresh token management from frontend to backend. Is that correct?  

> Am 14.02.2021 um 21:35 schrieb Vittorio Bertocci 
> :
> 
> Thanks!
> I expect the frontend (as in JS code) not to kick in until the initial 
> authorization has been perfomed. Breaking it down as a classic possible flow:
> 
> - User navigates to the app page, clicks "sign in"
> - The backend redirects the user to the AS to perform a code grant (for the 
> sake of argument let's also say they ask for an IDtoken as well tho it isn’t 
> strictly necessary), with the purpose of gathering consent for the scopes 
> required. No frontend code involved. 
> - The code grant concludes successfully, the backend now has a session with 
> the user agent and an AT, RT stored on the server side
> - --> here TMI-BFF begins. Whenever the frontend needs a token to call an 
> API, they use TMI-BFF to ask for that token to the backend
> - if the backend can return the requested token, via stored AT or by using 
> the RT, it does it
> - if the backend cannot get the requested token with what it already has 
> without suer interaction, it fails
> --> here there's where TMI-BFF ends- it's up to the backend to decide how to 
> meet the new requirements, eg by triggering another authorization code grant 
> for new scopes. The frontend is not involved apart from perhaps offering 
> affordances to the end upper to start such process
> 
> TMI-BFF does not include the actual authorization requests mostly for 
> simplicity. We don’t really know how the app is structured nor the reasons 
> for which a backend might be unable to get the requested token. The RT might 
> be expired; or the current scopes might be insufficient; or the AS might 
> decide that now issuing an AT with that scope might require a different 
> authentication method; and many other reasons I can’t think of. If we were to 
> provide a mechanism that includes in the error message indications on what 
> the frontent should do to remediate the error, we might need to either scope 
> down the scenarios or create a very flexible mechanism. I am not opposed, but 
> before venturing into that we wanted to see what the reaction would be.  
> 
> On 2/14/21, 11:45, "Torsten Lodderstedt" 
>  wrote:
> 
>Hi Vittorio,
> 
>thanks for the explanation. Do you assume the frontend passes the code or 
> initial refresh token to the backend using an application specific mechanism? 
> Why isn’t this part of the bff-token request?
> 
>best regards,
>Torsten.
> 
>> Am 14.02.2021 um 20:19 schrieb Vittorio Bertocci 
>> :
>> 
>> Hi Torsten, thanks for looking into this!
>> The idea is that the application backend performed all the interactive token 
>> acquisition steps before TMI-BFF come into play.
>> Imagine that a regular web app performs an authorization code grant, 
>> requesting access token and refresh token in the process (and often also 
>> setting its own session with the user agent in the process, if the AS is 
>> also their IdP via OIDC or similar, but that's not strictly necessary). Now 
>> the app backend has an access token and refresh token persisted on the 
>> server side.
>> All TMI-BFF does is to describe how the backend can share those tokens with 
>> its fronted, either directly (if the persisted AT is still valid) or 
>> indirectly (if it has to use an RT to obtain a new AT before sending it 
>> back).
>> The frontend provides resource and scope to select what token it needs, but 
>> the current idea is that the backend already obtained both consent and 
>> artifacts to obtain those tokens from the AS. And if it doesn't, at the 
>> moment we simply fail and expect the app developer to take the steps 
>> required to prompt the user with whatever is necessary for updating the 
>> backend with the right permissions, eg creating a new authorization request 
>> asking for a scope the frontend needs and that the user wasn't prompted to 
>> consent yet. At the moment TMI-BFF does not provide a mechanism for that 
>> prompt to occur, it just errors out saying "you've got to  update your 
>> authorization artifacts before the frontend can get the token w the scopes 
>> it needs".
>> Another way to think about this: in TMI-BFF the frontend treats the backend 
>> is a tokens database. Indicating the resource and scopes is a query. If the 
>> backend can serve that query (with the ATs it saved, or by using the RTs it 
>> saved AND the gran

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Torsten Lodderstedt]

Hi Vittorio,

thanks for the explanation. Do you assume the frontend passes the code or 
initial refresh token to the backend using an application specific mechanism? 
Why isn’t this part of the bff-token request?

best regards,
Torsten.

> Am 14.02.2021 um 20:19 schrieb Vittorio Bertocci 
> :
> 
> Hi Torsten, thanks for looking into this!
> The idea is that the application backend performed all the interactive token 
> acquisition steps before TMI-BFF come into play.
> Imagine that a regular web app performs an authorization code grant, 
> requesting access token and refresh token in the process (and often also 
> setting its own session with the user agent in the process, if the AS is also 
> their IdP via OIDC or similar, but that's not strictly necessary). Now the 
> app backend has an access token and refresh token persisted on the server 
> side.
> All TMI-BFF does is to describe how the backend can share those tokens with 
> its fronted, either directly (if the persisted AT is still valid) or 
> indirectly (if it has to use an RT to obtain a new AT before sending it back).
> The frontend provides resource and scope to select what token it needs, but 
> the current idea is that the backend already obtained both consent and 
> artifacts to obtain those tokens from the AS. And if it doesn't, at the 
> moment we simply fail and expect the app developer to take the steps required 
> to prompt the user with whatever is necessary for updating the backend with 
> the right permissions, eg creating a new authorization request asking for a 
> scope the frontend needs and that the user wasn't prompted to consent yet. At 
> the moment TMI-BFF does not provide a mechanism for that prompt to occur, it 
> just errors out saying "you've got to  update your authorization artifacts 
> before the frontend can get the token w the scopes it needs".
> Another way to think about this: in TMI-BFF the frontend treats the backend 
> is a tokens database. Indicating the resource and scopes is a query. If the 
> backend can serve that query (with the ATs it saved, or by using the RTs it 
> saved AND the grants the user already gave) it returns a token. If it 
> doesn't, it fails the query. The frontend does not play a direct role into 
> inserting in the DB more tokens. That is left to the backend, that can do so 
> by initiating a new authorization grant, not described in TMI-BFF, that must 
> conclude successfully for the frontend to be able to repeat its query and 
> this time get the token they want out. Note that the backend might decide 
> that it won’t try to get the token requested, or it might unable to do so (eg 
> the user/app cannot meet some requirements as the AS is concerned), hence the 
> request of it might at times be permanently denied. This last part is to say 
> that providing in the error message details about the remediation might take 
> more work than one realizes at first, and ultimately acting on the error 
> situation to retrieve a new token is still up to the backend anyway, hence 
> providing elaborate machinery to inform the frontend beyond the error 
> situation might not be as effective as it might look at first glance. I am 
> totally open to it, just making sure we understand what it can buy us.  
> 
> On 2/14/21, 06:11, "Torsten Lodderstedt" 
>  wrote:
> 
>Hi,
> 
>I’m trying to understand your proposal. 
> 
>Section 1.2, bullet (B) states
> 
>(B) If the backend does not already have a suitable access token
>  obtained in previous flows and cached, it requests to the
>  authorization server a new access token with the required
>  characteristics, using any artifacts previousy obtained (eg
>  refresh token) and grants that will allow the authorization server
>  to issue the requested token without requiring user interaction.
> 
>Can you please explain how the authorization process works towards the AS, 
> especially in case of the authorisation code grant type. I would have 
> expected to frontend to pass an authorisation code to the bff-token request. 
> 
>But section 4.1. only defines the parameters „resource" and „scope" for 
> the bff-token endpoint. 
> 
>thanks,
>Torsten. 
> 
>> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci 
>> :
>> 
>> Dear all,
>> Brian and yours truly are proposing a new specification that shows how the 
>> user agent frontend of a web app can delegate token acquisition and 
>> persistence to its backend, and request such tokens when needed for direct 
>> access of protected resources from the frontend code.
>> 
>> The pattern is already in use, in proprietary form, by various modern 
>> dev

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Torsten Lodderstedt]

Hi,

I’m trying to understand your proposal. 

Section 1.2, bullet (B) states

(B) If the backend does not already have a suitable access token
  obtained in previous flows and cached, it requests to the
  authorization server a new access token with the required
  characteristics, using any artifacts previousy obtained (eg
  refresh token) and grants that will allow the authorization server
  to issue the requested token without requiring user interaction.

Can you please explain how the authorization process works towards the AS, 
especially in case of the authorisation code grant type. I would have expected 
to frontend to pass an authorisation code to the bff-token request. 

But section 4.1. only defines the parameters „resource" and „scope" for the 
bff-token endpoint. 

thanks,
Torsten. 

> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci 
> :
> 
> Dear all,
> Brian and yours truly are proposing a new specification that shows how the 
> user agent frontend of a web app can delegate token acquisition and 
> persistence to its backend, and request such tokens when needed for direct 
> access of protected resources from the frontend code.
> 
> The pattern is already in use, in proprietary form, by various modern 
> development stacks, such as Next.JS. Variants of the pattern, often discussed 
> under the catch-all term BFF (backend for frontend), have been often 
> mentioned in this workgroup’s activity, but always left all implementation 
> details to the reader.
> We believe the pattern has merit, as corroborated by its growing adoption. By 
> delegating access token acquisition to the backend, we avoid many of the 
> often brittle moving parts (and implied attack surface) required to acquire 
> access tokens from a user agent. The topology also relieves the frontend from 
> the need of persisting tokens in local storage, a well known sore point of 
> using OAuth directly in JavaScript, by relying on its backend storage and 
> session to preserve tokens.
> 
> Although the specification is very simple, providing explicit guidance on the 
> scenario offers many advantages.  
> - It makes it possible to create interoperable SDKs, where frontend dev 
> stacks (any JS flavor) can be mixed and matched with compliant backend stacks 
> (middlewares in node, java, ASP.NET, PHP etc)
> - It allows us to provide guidance on how to properly tackle the scenario and 
> warn implementers against security risks (scope escalations, using IDtokens 
> instead of access tokens, etc)
> - It allows us to discuss (and when appropriate, promote) this pattern as 
> part of the browser apps security guidance, and position the scenario where 
> frontend only calls API on its own backed (hence doesn’t need access tokens) 
> simply as a special case of this more general pattern
> - This approach makes mocking and testing apps very easy, possibly preventing 
> developers from weakening the security of their system (eg turning on ROPG 
> options)  or turning to risky practices like scraping
> 
> Needless to say, this specification doesn’t entirely eliminate the risks 
> inherent to direct use of access tokens from a browser. But reality is that 
> the pattern is in widespread use, and the circumstances leading to that (eg 
> developers on a particular project only work with frontend stacks; components 
> like reverse proxies might not always be viable; etc) aren’t going away any 
> time soon. By providing simple guidance on this pattern, we can simplify the 
> life of many developers while enshrining basic security hygiene in scenarios 
> that would have otherwise be left to their own device.
> 
> Looking forward for your feedback!
> 
> B  
> 
> On 2/12/21, 12:41, "internet-dra...@ietf.org"  
> wrote:
> 
> 
>A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
>has been successfully submitted by Vittorio Bertocci and posted to the
>IETF repository.
> 
>Name:  draft-bertocci-oauth2-tmi-bff
>Revision:  00
>Title: Token Mediating and session Information Backend For 
> Frontend
>Document date: 2021-02-12
>Group: Individual Submission
>Pages: 16
>URL:
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt=gmail-imap=161376759100=AOvVaw3Rb-S0l6cEv0ytjDxtYLAP
>Status: 
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/=gmail-imap=161376759100=AOvVaw3-qg5MDtY7kD1HpR5jR2QY
>Html:   
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html=gmail-imap=161376759100=AOvVaw05WK4GSEKcWjZzNhvb1p5d
>Htmlized:   
> https://www.google.com/url?q=https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00=gmail-imap=161376759100=AOvVaw0qm45MWGbZf0zbBjZj3ggz
> 
> 
>Abstract:
>   This document describes how a JavaScript frontend can 

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

[Torsten Lodderstedt]

> Am 08.02.2021 um 00:56 schrieb Warren Parad :
> 
> 
>> I‘m therefore leaning towards explicitly stating in our draft that it is not 
>> intended to be used with refresh tokens.
> I'm not following, why explicitly state that it isn't intended. If an AS 
> wants to provide a similar JSON response to a query with the refresh token, 
> why not encourage that?

Why should we encourage it? 

> 
>   
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement 
> Authress.
> 
> 
>> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt 
>>  wrote:
>> Hi Andrii,
>> 
>>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega :
>>>> 
>>> 
>>> Hi Torsten,
>>> 
>>> thank you for your response.
>>> 
>>> My use case is pretty straight forward
>>> 
>>> An OAuth client queries the AS to determine the active state of an access 
>>> token and gets the introspection response which indicates that this access 
>>> token is active (using RFC7662).
>>> 
>>> An OAuth client queries the AS to determine the active state of a refresh 
>>> token and gets the introspection response which indicates that this refresh 
>>> token is active (using RFC7662).
>>> 
>>> An OAuth client queries the AS to determine the active state of an access 
>>> token and gets the introspection response (JWT) which indicates that this 
>>> access token is active (using this draft).
>>> 
>>> Now, an OAuth client queries the AS to determine the active state of a 
>>> refresh token (using this draft)... How will the introspection response 
>>> look like assuming that the client provides the valid refresh token and 
>>> technically, nothing stops it from doing so.
>> 
>> why should the state be provided as JWT?I think the plain JSON response is 
>> sufficient in that case.  I also think using token introspection for 
>> checking the state of a token from the client side has limited utility. The 
>> definitive decision is always made when the client tries to access a 
>> resource. 
>> 
>> I‘m therefore leaning towards explicitly stating in our draft that it is not 
>> intended to be used with refresh tokens.
>> 
>> best regards,
>> Torsten.
>> 
>>> 
>>> Regards,
>>> Andrii
>>> 
>>> 
>>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt 
>>>>  wrote:
>>>> Hi Andrii,
>>>> 
>>>> thanks for your post. 
>>>> 
>>>> The draft is intended to provide AS and RS with a solution to exchange 
>>>> signed (and optionally encrypted) token introspection responses in order 
>>>> to provide stronger assurance among those parties. This is important in 
>>>> use cases where the RS acts upon the introspection response data and wants 
>>>> the AS to take liability re the data quality. 
>>>> 
>>>> I’m not sure whether there are similar use cases if a client introspects a 
>>>> refresh token. What is your use case?
>>>> 
>>>> best regards,
>>>> Torsten.  
>>>> 
>>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega :
>>>> > 
>>>> > Hi WG,
>>>> > 
>>>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 
>>>> > Token Introspection [RFC7662] specifies a method for a protected 
>>>> > resource to query an OAuth 2.0 authorization server to determine the 
>>>> > state of an access token and obtain data associated with the access 
>>>> > token." which is true. Although, according to RFC7662, the introspection 
>>>> > endpoint allows to introspect a refresh token as well. Hence, the 
>>>> > question I have is how will a token introspection response look like 
>>>> > when the caller provides a refresh token and sets the "Accept" HTTP 
>>>> > header to "application/token-introspection+jwt"?
>>>> > 
>>>> > I expect there will be no differences, right?
>>>> > 
>>>> > If so, I suggest to
>>>> >   • replace "a resource server" by "the caller" in section 4 
>>>> > (Requesting a JWT Response)
>>>> >   • change "If the access token is invalid, expired, revoked" by "If 
>>>> > a given token is invalid, expired, revoked" in section 5 (JWT Response)
>>>> > If not, my suggestion would be to clarify what the AS should do when it 
>>>> > asked to introspect the refresh token in general and additionally, what 
>>>> > should happen in the same case based on the type of the caller from the 
>>>> > AS's point of view.
>>>> > 
>>>> > Regards,
>>>> > Andrii
>>>> > 
>>>> 
>> ___
>> 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] JWT Response for OAuth Token Introspection and types of tokens

[Torsten Lodderstedt]

Hi Andrii,

> Am 07.02.2021 um 21:30 schrieb Andrii Deinega :
> 
> 
> Hi Torsten,
> 
> thank you for your response.
> 
> My use case is pretty straight forward
> 
> An OAuth client queries the AS to determine the active state of an access 
> token and gets the introspection response which indicates that this access 
> token is active (using RFC7662).
> 
> An OAuth client queries the AS to determine the active state of a refresh 
> token and gets the introspection response which indicates that this refresh 
> token is active (using RFC7662).
> 
> An OAuth client queries the AS to determine the active state of an access 
> token and gets the introspection response (JWT) which indicates that this 
> access token is active (using this draft).
> 
> Now, an OAuth client queries the AS to determine the active state of a 
> refresh token (using this draft)... How will the introspection response look 
> like assuming that the client provides the valid refresh token and 
> technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is 
sufficient in that case.  I also think using token introspection for checking 
the state of a token from the client side has limited utility. The definitive 
decision is always made when the client tries to access a resource. 

I‘m therefore leaning towards explicitly stating in our draft that it is not 
intended to be used with refresh tokens.

best regards,
Torsten.

> 
> Regards,
> Andrii
> 
> 
>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt  
>> wrote:
>> Hi Andrii,
>> 
>> thanks for your post. 
>> 
>> The draft is intended to provide AS and RS with a solution to exchange 
>> signed (and optionally encrypted) token introspection responses in order to 
>> provide stronger assurance among those parties. This is important in use 
>> cases where the RS acts upon the introspection response data and wants the 
>> AS to take liability re the data quality. 
>> 
>> I’m not sure whether there are similar use cases if a client introspects a 
>> refresh token. What is your use case?
>> 
>> best regards,
>> Torsten.  
>> 
>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega :
>> > 
>> > Hi WG,
>> > 
>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 
>> > Token Introspection [RFC7662] specifies a method for a protected resource 
>> > to query an OAuth 2.0 authorization server to determine the state of an 
>> > access token and obtain data associated with the access token." which is 
>> > true. Although, according to RFC7662, the introspection endpoint allows to 
>> > introspect a refresh token as well. Hence, the question I have is how will 
>> > a token introspection response look like when the caller provides a 
>> > refresh token and sets the "Accept" HTTP header to 
>> > "application/token-introspection+jwt"?
>> > 
>> > I expect there will be no differences, right?
>> > 
>> > If so, I suggest to
>> >   • replace "a resource server" by "the caller" in section 4 
>> > (Requesting a JWT Response)
>> >   • change "If the access token is invalid, expired, revoked" by "If a 
>> > given token is invalid, expired, revoked" in section 5 (JWT Response)
>> > If not, my suggestion would be to clarify what the AS should do when it 
>> > asked to introspect the refresh token in general and additionally, what 
>> > should happen in the same case based on the type of the caller from the 
>> > AS's point of view.
>> > 
>> > Regards,
>> > Andrii
>> > 
>> 


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-rar-04.txt

[Torsten Lodderstedt]

Hi all,

here is the list of changes in revision -04:

restructured draft for better readability
simplified normative text about use of the resource parameter with 
authorization_details 
added implementation considerations for deployments and products
added type union language from GNAP  
added recommendation to use PAR to cope with large requests and for request 
protection

Your feedback is highly appreciated.

best regards,
Torsten. 

> Am 07.02.2021 um 13:42 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 Rich Authorization Requests
>    Authors     : Torsten Lodderstedt
>  Justin Richer
>  Brian Campbell
>   Filename: draft-ietf-oauth-rar-04.txt
>   Pages   : 36
>   Date: 2021-02-07
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> 
> 
> The IETF datatracker status page for this draft is:
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/=gmail-imap=161330655700=AOvVaw3-4SmuMFgxbz-cDK2Ir_a7
> 
> There is also an HTML version available at:
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.html=gmail-imap=161330655700=AOvVaw1J52xGTvk1ZAuBC_fUAIjJ
> 
> A diff from the previous version is available at:
> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-04=gmail-imap=161330655700=AOvVaw0TYqmFwryvAYznR2Ho5Oj6
> 
> 
> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=161330655700=AOvVaw06g1z6o36BkkaqkiWc1Lw9

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

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

[Torsten Lodderstedt]

Hi Andrii,

thanks for your post. 

The draft is intended to provide AS and RS with a solution to exchange signed 
(and optionally encrypted) token introspection responses in order to provide 
stronger assurance among those parties. This is important in use cases where 
the RS acts upon the introspection response data and wants the AS to take 
liability re the data quality. 

I’m not sure whether there are similar use cases if a client introspects a 
refresh token. What is your use case?

best regards,
Torsten.  

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega :
> 
> Hi WG,
> 
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 Token 
> Introspection [RFC7662] specifies a method for a protected resource to query 
> an OAuth 2.0 authorization server to determine the state of an access token 
> and obtain data associated with the access token." which is true. Although, 
> according to RFC7662, the introspection endpoint allows to introspect a 
> refresh token as well. Hence, the question I have is how will a token 
> introspection response look like when the caller provides a refresh token and 
> sets the "Accept" HTTP header to "application/token-introspection+jwt"?
> 
> I expect there will be no differences, right?
> 
> If so, I suggest to
>   • replace "a resource server" by "the caller" in section 4 (Requesting 
> a JWT Response)
>   • change "If the access token is invalid, expired, revoked" by "If a 
> given token is invalid, expired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked 
> to introspect the refresh token in general and additionally, what should 
> happen in the same case based on the type of the caller from the AS's point 
> of view.
> 
> Regards,
> Andrii
> 

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

Re: [OAUTH-WG] PAR error for redirect URI?

[Torsten Lodderstedt]



> Am 14.12.2020 um 17:39 schrieb Brian Campbell 
> :
> 
> 
> And that's done: 
> https://mailarchive.ietf.org/arch/msg/oauth/W0eq4HUiiLVS5F5qyXXY6Gdw7vs/
> 
>> On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt 
>>  wrote:
>> +1 for following Vladimir’s proposal
>> 
>> > Am 14.12.2020 um 14:54 schrieb Brian Campbell 
>> > :
>> > 
>> > er, I mean an -05 
>> > 
>> > On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell 
>> >  wrote:
>> > Thanks Vladimir, that seems quite reasonable. Barring any objections, I'll 
>> > add that to a -04. 
>> > 
>> > On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov 
>> >  wrote:
>> > Hi Brian,
>> > 
>> > I'd like to propose the sentence in bold to be inserted into the current 
>> > section 2.3 of PAR -04:
>> > 
>> > https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-2.3
>> > 
>> > The authorization server returns an error response with the same format as 
>> > is specified for error responses from the token endpoint in Section 5.2 of 
>> > [RFC6749] using the appropriate error code from therein or from Section 
>> > 4.1.2.1 of [RFC6749]. In those cases where Section 4.1.2.1 of [RFC6749] 
>> > prohibits automatic redirection with an error back to the requesting 
>> > client and hence doesn’t define an error code, for example when the 
>> > request fails due to a missing, invalid, or mismatching redirection URI, 
>> > the “invalid_request” error code can be used as the default error code.
>> > 
>> > Hope with this we can close the case.
>> > 
>> > Vladimir
>> > 
>> > 
>> > On 04/12/2020 18:08, Brian Campbell wrote:
>> >> 
>> >> 
>> >> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov 
>> >>  wrote:
>> >> If people have articulated a need to have an invalid_redirect_uri error 
>> >> for the PAR endpoint, then let's register it properly. Rifaat says 
>> >> there's still time to do this.
>> >> 
>> >> 
>> >> Following from the response I recently sent to Neil, I don't think a 
>> >> legitimate need has been articulated. 
>> >> https://mailarchive.ietf.org/arch/msg/oauth/gMiH1mTr0AKDvWpqO1zikcVUySY/
>> >>  
>> >> I'm also okay with using the general invalid_request code for this. In 
>> >> this case a sentence, next to the current example, spelling out what the 
>> >> PAR endpoint must do on a invalid redirect URI will help.
>> >> 
>> >> I don't know that that's needed either. But do have some text to suggest 
>> >> that you think would be helpful? 
>> >> 
>> >>  
>> >> 
>> >> Vladimir
>> >> 
>> >> On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote:
>> >>> Torsten, Filip,
>> >>> 
>> >>> You can absolutely make this change, as we are still very early in the 
>> >>> process. 
>> >>> So feel free to continue this effort and try to get WG agreement on 
>> >>> this, and update the document as needed. 
>> >>> 
>> >>> Regards,
>> >>>  Rifaat
>> >>> 
>> >>> 
>> >>> On Thursday, December 3, 2020, Filip Skokan  wrote:
>> >>> To be clear, I'm not advocating to skip the registration, just wanted to 
>> >>> mention a potential concern. If the process allows it and it will not 
>> >>> introduce more delay to publication, I think we should go ahead and 
>> >>> register the error code.
>> >>> 
>> >>> Best,
>> >>> Filip
>> >>> 
>> >>> 
>> >>> On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt 
>> >>>  wrote:
>> >>> 
>> >>> 
>> >>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
>> >>> > 
>> >>> > There are several documents already mentioning "invalid_redirect_uri" 
>> >>> > as an error code, specifically RFC7519 and OpenID Connect Dynamic 
>> >>> > Client Registration 1.0. But these don't register it in the IANA OAuth 
>> >>> > Extensions Error Registry, presumably because they're neither for the 
>> >>> > authorization or token endpoints.
>> >>> > 
>> >>> > While I think it'd be great if we had this error code

Re: [OAUTH-WG] PAR error for redirect URI?

[Torsten Lodderstedt]

+1 for following Vladimir’s proposal

> Am 14.12.2020 um 14:54 schrieb Brian Campbell 
> :
> 
> er, I mean an -05 
> 
> On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell  
> wrote:
> Thanks Vladimir, that seems quite reasonable. Barring any objections, I'll 
> add that to a -04. 
> 
> On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov  
> wrote:
> Hi Brian,
> 
> I'd like to propose the sentence in bold to be inserted into the current 
> section 2.3 of PAR -04:
> 
> https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-2.3
> 
> The authorization server returns an error response with the same format as is 
> specified for error responses from the token endpoint in Section 5.2 of 
> [RFC6749] using the appropriate error code from therein or from Section 
> 4.1.2.1 of [RFC6749]. In those cases where Section 4.1.2.1 of [RFC6749] 
> prohibits automatic redirection with an error back to the requesting client 
> and hence doesn’t define an error code, for example when the request fails 
> due to a missing, invalid, or mismatching redirection URI, the 
> “invalid_request” error code can be used as the default error code.
> 
> Hope with this we can close the case.
> 
> Vladimir
> 
> 
> On 04/12/2020 18:08, Brian Campbell wrote:
>> 
>> 
>> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov  
>> wrote:
>> If people have articulated a need to have an invalid_redirect_uri error for 
>> the PAR endpoint, then let's register it properly. Rifaat says there's still 
>> time to do this.
>> 
>> 
>> Following from the response I recently sent to Neil, I don't think a 
>> legitimate need has been articulated. 
>> https://mailarchive.ietf.org/arch/msg/oauth/gMiH1mTr0AKDvWpqO1zikcVUySY/
>>  
>> I'm also okay with using the general invalid_request code for this. In this 
>> case a sentence, next to the current example, spelling out what the PAR 
>> endpoint must do on a invalid redirect URI will help.
>> 
>> I don't know that that's needed either. But do have some text to suggest 
>> that you think would be helpful? 
>> 
>>  
>> 
>> Vladimir
>> 
>> On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote:
>>> Torsten, Filip,
>>> 
>>> You can absolutely make this change, as we are still very early in the 
>>> process. 
>>> So feel free to continue this effort and try to get WG agreement on this, 
>>> and update the document as needed. 
>>> 
>>> Regards,
>>>  Rifaat
>>> 
>>> 
>>> On Thursday, December 3, 2020, Filip Skokan  wrote:
>>> To be clear, I'm not advocating to skip the registration, just wanted to 
>>> mention a potential concern. If the process allows it and it will not 
>>> introduce more delay to publication, I think we should go ahead and 
>>> register the error code.
>>> 
>>> Best,
>>> Filip
>>> 
>>> 
>>> On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> 
>>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
>>> > 
>>> > There are several documents already mentioning "invalid_redirect_uri" as 
>>> > an error code, specifically RFC7519 and OpenID Connect Dynamic Client 
>>> > Registration 1.0. But these don't register it in the IANA OAuth 
>>> > Extensions Error Registry, presumably because they're neither for the 
>>> > authorization or token endpoints.
>>> > 
>>> > While I think it'd be great if we had this error code registered, I also 
>>> > worry that its registration could confuse implementers to think it's okay 
>>> > to return it from the authorization endpoint.
>>> 
>>> I understand your concern. On the other hand, registering the error code is 
>>> in my opinion the proper way forward. The registration is scoped to a usage 
>>> location, should be pushed authorization endpoint then, and RFC6749 gives 
>>> clear guidance on how to treat errors related to the redirect URI at the 
>>> authorization endpoint. 
>>> 
>>> "If the request fails due to a missing, invalid, or mismatching
>>>redirection URI, … authorization server ... MUST NOT automatically 
>>> redirect the user-agent to the
>>>invalid redirection URI."
>>> 
>>> I think if an implementor ignores this, it will ignore any advise.
>>> 
>>> best regards,
>>> Torsten. 
>>> 
>>> > 
>>> > Best,
>>> > Filip
>>> > 
>>&g

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Torsten Lodderstedt]

Hi Neil,

thanks for your comprehensive answers. Please find my comments inline.

best regards,
Torsten.

> Am 12.12.2020 um 21:11 schrieb Neil Madden :
> 
> 
> Good questions! Answers inline:
> 
>>> On 12 Dec 2020, at 10:07, Torsten Lodderstedt  
>>> wrote:
>>> 
>> 
>> Thanks for sharing, Neil!
>> 
>> I‘ve got some questions:
>> Note: I assume the tokens you are referring in your article are OAuth access 
>> tokens.
> 
> No, probably not. Just auth tokens more generically. 
> 
>> - carrying tokens in URLs wie considered bad practice by the Security BCP 
>> and OAuth 2.1 due to leakage via referrer headers and so on. Why isn’t this 
>> an issue with your approach?
> 
> This is generally safe advice, but it is often over-cautious for three 
> reasons:
> 
> 1. Referer headers (and window.referrer) apply when embedding/linking 
> resources in HTML. But when we’re talking about browser-based apps (eg SPAs), 
> that usually means JavaScript calling some backend API that returns JSON or 
> some other data format. These data formats don’t have links or embedded 
> resources (as far as the browser is concerned), so they don’t leak Referer 
> headers in the same way. When the app loads a resource from a URI in a JSON 
> response the Referer header will contain the URI of the app itself (most 
> likely a generic HTML template page), not the capability URI from which the 
> JSON was loaded. Similar arguments apply to browser history and other typical 
> ways that URIs leak. 
> 
> 2. You can now use the Referrer-Policy header [1] and rel=“noopener 
> noreferrer” to opt out of this leakage, and browsers are moving to doing this 
> by default for cross-origin requests/embeds. (This is already enabled by 
> default in Safari). 
> 
> 3. When you do want to use capability URIs for top-level navigation, there 
> are places in the URI you can put a token that aren’t ever included in 
> Referer headers or window.referrer or ever sent to the server at all - such 
> as the fragment. JavaScript can then extract the token from the fragment (and 
> then wipe it) and send it to the server in an Authorization header or 
> whatever. See [2] for more details and alternatives. 
> 
> [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
> [2]: 
> https://neilmadden.blog/2019/01/16/can-you-ever-safely-include-credentials-in-a-url/
> 
>> - generating (self contained) or using (handles) per URL access tokens might 
>> be rather expensive. Can you sketch out how you wanna cope with that 
>> challenge?
> 
> A decent HMAC implementation takes about 1-2 microseconds for typical size of 
> token we’re talking about. 

The generation of a self contained access token typically requires querying 
claim values from at least a single data source. That might take more time. For 
handle based tokens/token introspection, one needs to add the time it takes to 
obtain the token data, which requires a HTTPS communication. That could be even 
more time consuming.

> 
>> - per URL Access tokens are a very consequent Form or audience restriction. 
>> How do you wanna signal the audience to the AS?
> 
> As I said, this isn’t OAuth, but for example you can already do this with the 
> macaroon access tokens in ForgeRock AM 7.0 - issue a single access token and 
> then make copies with specific audience restrictions added as caveats, as 
> discussed in [3]. Such audience restrictions are then returned in the token 
> introspection response and the RS can enforce them. 

> 
> My comment in the article about ideas for future OAuth is really just that 
> the token endpoint should be able to issue multiple fine-grained access 
> tokens in one go, each associated with a particular endpoint (or endpoints). 
> You could either return these as separate items like:
> 
> “access_tokens”: [
> { “token”: “abc...”, 
>“aud”: “https://api.example.com/foo” },
> { “token”: “def...”,
>“aud”: “https://api.example.com/bar” }
> ]

I like the idea (and have liked it for a long time  
https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/).

resource indicators or authorization_details (with locations) could basically 
be used for that purpose but OAuth2 lacks multiple tokens support in the token 
endpoint.

> 
> Or just go ahead and combine those into capability URIs. (I think I already 
> mentioned this a long time ago when GNAP was first being discussed). 
> 
> Speaking even more wishfully, what I would really love to see is a new URL 
> scheme for these, something like:
> 
>   bearer://@api.example.com/foo
> 
> Which is equivalent to a HTTPS link, but the browser knows about this format 
&

Re: [OAUTH-WG] Detailed review of OAuth2.1

[Torsten Lodderstedt]

Thanks as lot Vittorio! You gave us a lot of homework but I think the draft 
will be improved a lot based on it.

Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit 
(response type „id_token“ or „code id_token“) as there are examples in the wild 
where the id_token is used as access token. Moreover, I‘m not aware of any 
systematic security threat analysis of those flows.

I‘m fine with pointing out to readers that omission of response type „token“ 
does not deprecate other extension response types.

WDYT?

> Am 09.12.2020 um 01:55 schrieb Dick Hardt :
> 
> 
> Thank you very much for your detailed feedback Vittorio!
> ᐧ
> 
>> On Tue, Dec 8, 2020 at 3:22 PM  wrote:
>> Dear authors,
>> 
>> It took ages but I finally managed to go thru a full review of the current 
>> OAuth2.1 draft. Apologies for the delay.
>> 
>> Metacomments:
>> 
>> The VAST majority of the comments are suggestions for improving clarity, 
>> mostly on historical language coming from 2.0 that I found myself having to 
>> clarify to customers and colleagues over and over thru the years. None of 
>> those are critical.
>> There are a few places where 2.1 requires a MUST I believe to be 
>> unwarranted/too restrictive. For each of those I did my best to provide 
>> context and concrete examples.
>> A sizeable category of comments and disagreements on MUST come from treating 
>> mobile and desktop apps as largely equivalent under the “native app” 
>> umbrella, despite of the vast gulf that separates the two both in terms of 
>> security posture and user experience. Again, I tried to be as matter of fact 
>> as possible in there.
>> The main reason for which I spoke up during the IETF interim on oauth2.1 was 
>> the confusion the omission f the implicit grant caused among the devs using 
>> implicit in OIDC for obtaining ID_tokens. I suggested some language to 
>> pre-empt the issue, but I expect some iteration there.
>> Thanks,
>> 
>> V
>> 
>>  
>> 
>> §1
>> 
>> I wonder whether we should take the opportunity offered by OAuth2.1 to 
>> clarify frequent points of confusion about OAuth, by explicitly calling out 
>> in the introduction what is out of scope.
>> 
>> For example: OAuth is not an identity protocol, as it doesn’t concern itself 
>> with how resource owners are authenticated; OAuth isn’t meant to address 1st 
>> party scenarios, although the reader is free to use it in that context as 
>> well; and so on.
>> 
>> I believe there is value in adding this in the introduction rather than 
>> relegating it in some later considerations section, as the people who need 
>> this information the most rarely read past this point.
>> 
>>  
>> 
>> §1.1
>> 
>> In the RS definition, wondering whether including the word “API” would help 
>> to clarify what an RS is in practice.
>> 
>>  
>> 
>> §1.2
>> 
>> I always found this part extraordinarily difficult to decipher. I get that 
>> this is the first description and doesn’t have to be exhaustive and consider 
>> all cases (eg it’s ok if step 3 claims that the client authenticates w the 
>> AS even tho that’s only for confidential clients), but I think it could be 
>> much clearer than it is today.
>> 
>> Step 1 says
>> 
>> The client requests authorization from the resource owner.  The 
>> authorization request can be made directly to the resource owner (as shown), 
>> or preferably indirectly via the authorization server as an intermediary.
>> 
>> Besides the fact that “requests authorization” is a bit vague, this step and 
>> the corresponding diagram leg does not correspond at all to what normally 
>> happens- to get a code, the client does need to hit the AS and the mention 
>> in passing in the text isn’t enough to figure that out. Also, with the 
>> omission of ROPG there really isn’t any way of asking anything to the RO 
>> directly (the client creds doesn’t involve the RO).
>> 
>> I would recommend updating that diagram to be more descriptive of the 
>> canonical scenario.
>> 
>> Step 2
>> 
>> mentions the 2 grants defined in the spec, but only one of them represents 
>> the RO’s authorization. Claiming that the client itself is the RO is a 
>> formalism that doesn’t meet the reader’s intuition at this point.
>> 
>> Step 5
>> 
>> The language here triggered multiple discussions, in particular on whether 
>> the AT can actually be used to ascertain the identity of the client – that 
>> isn’t the case for public clients, for example; besides, that’s not really 
>> the highest order bit of the AT. If it is, it seems that the spec should be 
>> more explicit about how client identification from the RS by means of an AT 
>> works. If it isn’t, perhaps we should change the language to omit 
>> authenticate.
>> 
>> The last paragraph is emblematic IMO – if the preferred method is very 
>> different from the diagram here, and if the abstraction presented here is 
>> not terribly useful (given that we no longer have multiple RO based grants, 
>> excluding the extension grants 

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Torsten Lodderstedt]

Thanks for sharing, Neil!

I‘ve got some questions:
Note: I assume the tokens you are referring in your article are OAuth access 
tokens.
- carrying tokens in URLs wie considered bad practice by the Security BCP and 
OAuth 2.1 due to leakage via referrer headers and so on. Why isn’t this an 
issue with your approach?
- generating (self contained) or using (handles) per URL access tokens might be 
rather expensive. Can you sketch out how you wanna cope with that challenge?
- per URL Access tokens are a very consequent Form or audience restriction. How 
do you wanna signal the audience to the AS?

best regards,
Torsten.

> Am 12.12.2020 um 08:26 schrieb Neil Madden :
> 
> 
> Not directly related to DPoP or OAuth, but I wrote some notes to help 
> recovering XSS Nihilists: 
> https://neilmadden.blog/2020/12/10/xss-doesnt-have-to-be-game-over/
> 
> — Neil
> 
>>> On 12 Dec 2020, at 00:02, Brian Campbell 
>>>  wrote:
>>> 
>> 
>> I think that puts Jim in the XSS Nihilism camp :) 
>> 
>> Implicit type flows are being deprecated/discouraged. But keeping tokens out 
>> of browsers doesn't seem likely. There is some menton of CSP in 
>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7
>>  
>> 
>>> On Wed, Dec 9, 2020 at 4:10 PM Jim Manico  wrote:
>>> The basic theme from the web attacker community is:
>>> 
>>> 1) XSS is a game over event to web clients. XSS can steal or abuse (request 
>>> forgery) tokens, and more.
>>> 
>>> 2) Even if you prevent stolen tokens from being used outside of a web 
>>> client, XSS still allows the attacker to force a user to make any request 
>>> in a fraudulent way, abusing browser based tokens as a form of request 
>>> forgery.
>>> 
>>> 3) There are advanced measures to stop a token from being stolen from a web 
>>> client, like a HTTPonly cookies and to a lesser degree, JS Closures and 
>>> Webworkers. 
>>> 
>>> 4) However, these measures to protect cookies are mostly moot. Attackers 
>>> can just force clients to make fraudulent requests.
>>> 
>>> 5) Many recommend the BFF pattern to hide tokens on the back end, but 
>>> still, request forgery via XSS allows all kinds of abuse.
>>> 
>>> XSS is game over no matter how you slice it.
>>> 
>>> Crypto solutions do not help. Perhaps the world of OAuth can start 
>>> suggesting that web clients use CSP 3.0 in specific ways, if you still plan 
>>> to support Implicit type flows or tokens in browsers?
>>> 
>>> Respectfully,
>>> 
>>> - Jim
>>> 
>>> 
>>> 
>>> On 12/9/20 12:57 PM, Brian Campbell wrote:
 Thanks Philippe, I very much concur with your line of reasoning and the 
 important considerations. The scenario I was thinking of is: browser based 
 client where XSS is used to exfiltrate the refresh token along with 
 pre-computed proofs that would allow for the RT to be exchanged for new 
 access tokens and also pre-computed proofs that would work with those 
 access tokens for resource access. With the pre-computed proofs that would 
 allow prolonged (as long as the RT is valid) access to protected resources 
 even when the victim is offline. Is that a concrete attack scenario? I 
 mean, kind of. It's pretty convoluted/complex. And while an access token 
 hash would reign it in somewhat (ATs obtained from the stolen RT wouldn't 
 be usable) it's hard to say if the cost is worth the benefit.
 
 
 
 On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck 
  wrote:
> Yeah, browser-based apps are pure fun, aren’t they? :)
> 
> The reason I covered a couple of (pessimistic) XSS scenarios is that the 
> discussion started with an assumption that the attacker already 
> successfully exploited an XSS vulnerability. I pointed out how, at that 
> point, finetuning DPoP proof contents will have little to no effect to 
> stop an attack. I believe it is important to make this very clear, to 
> avoid people turning to DPoP as a security mechanism for browser-based 
> applications.
> 
> 
> Specifically to your question on including the hash in the proof, I think 
> these considerations are important:
> 
> 1. Does the inclusion of the AT hash stop a concrete attack scenario?
> 2. Is the “cost” (implementation, getting it right, …) worth the benefits?
> 
> 
> Here’s my view on these considerations (specifically for browser-based 
> apps, not for other types of applications):
> 
> 1. The proof precomputation attack is already quite complex, and short 
> access token lifetimes already reduce the window of attack. If the 
> attacker can steal a future AT, they could also precompute new proofs 
> then. 
> 2. For browser-based apps, it seems that doing this complicates the 
> implementation, without adding much benefit. Of course, libraries could 
> handle this, which significantly reduces the cost. 
> 
> 
> Note that these comments are specifically to 

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

[Torsten Lodderstedt]

I support the WG adoption of this draft. 

> Am 08.12.2020 um 13:50 schrieb Rifaat Shekh-Yusef :
> 
> All,
> 
> This is a call for adoption for the following AS Issuer Identifier in 
> Authorization Response as a WG document:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
> 
> Please, provide your feedback on the mailing list by Dec 22nd.
> 
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=160803665600=AOvVaw3LQv8gGHF-mvbizMYxf_54

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

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Torsten Lodderstedt]

I understand. Thanks! 

I think RT rotation + RT hash in the proof would also stop the attack.  

> Am 03.12.2020 um 13:19 schrieb Filip Skokan :
> 
> I'm failing to understand why binding the proof to the access token ensures 
> freshness of the proof.
> 
> Because when access tokens issued to public browser based clients have a 
> short duration you need continued access to the private key to issue new 
> proofs. When I exfiltrate the RT and pre-generate tons of proofs while the 
> user is active on the page through XSS I can then use the RT and my prepared 
> proofs to talk to the AS to keep on refreshing the AT and use it against the 
> RS. When the value of the token is part of the proof, i cannot pre-generate 
> them for future issued access tokens. Short `iat` based windows don't help 
> here.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Thu, 3 Dec 2020 at 12:59, Torsten Lodderstedt  
> wrote:
> Hi, 
> 
> I'm failing to understand why binding the proof to the access token ensures 
> freshness of the proof. I would rather think if the client is forced to 
> create proofs with a reasonable short lifetime, chances for replay could be 
> reduced. 
> 
> Beside that as far as I remember the primary replay counter measure is the 
> inclusion of the endpoint URL and HTTP method in the proof, since it reduces 
> the attack surface to a particular URL. So in the context of freshness, we 
> are talking about using the same proof with the same URL again. 
> 
> best regards,
> Torsten. 
> 
> > Am 03.12.2020 um 10:20 schrieb Filip Skokan :
> > 
> > Hi Brian, everyone,
> > 
> > While the attack vector allows direct use, there is the option where a 
> > smarter attacker will not abuse the gained artifacts straight away. Think 
> > public client browser scenario with the non-extractable private key stored 
> > in IndexedDB (the only place to persist them really), they wouldn't use the 
> > tokens but instead, exfiltrate them, together with a bunch of pre-generated 
> > DPoP proofs. They'll get the refresh token and a bunch of DPoP proofs for 
> > both the RS and AS. With those they'll be able to get a fresh AT and use it 
> > with pre-generated Proofs after the end-user leaves the site. No available 
> > protection (e.g. RT already rotated) will be able to kick in until the 
> > end-user opens the page again.
> > 
> > OTOH with a hash of the AT in the Proof only direct use remains.
> > 
> > If what I describe above is something we don't want to deal with because of 
> > direct use already allowing access to protected resources, it's 
> > sufficiently okay as is (option #1). However, if this scenario, one 
> > allowing prolonged access to protected resources, is not acceptable, it's 
> > option #2.
> > 
> > Ad #2a vs #2b vs #2c. My pre-emptive answer is #2a, simply because we 
> > already have the tools needed to generate and validate these hashes. But 
> > further thinking about it, it would feel awkward if this JWS algorithm 
> > driven at_hash digest selection wouldn't get stretched to the 
> > confirmations, when this are placed in a JWT access token, cool - we can do 
> > that, but when these are put in a basic token introspection response it's 
> > unfortunately not an option. So, #2b (just use sha-256 just like the 
> > confirmations do).
> > 
> > Best,
> > Filip
> > 
> > 
> > On Wed, 2 Dec 2020 at 21:50, Brian Campbell 
> >  wrote:
> > There were a few items discussed somewhat during the recent interim that I 
> > committed to bringing back to the list. The slide below (also available as 
> > slide #17 from the interim presentation) is the first one of them, which is 
> > difficult to summarize but kinda boils down to how much assurance there is 
> > that the DPoP proof was 'freshly' created and that can dovetail into the 
> > question of whether the token is covered by the signature of the proof. 
> > There are many directions a "resolution" here could go but my sense of the 
> > room during the meeting was that the contending options were:
> >   •  It's sufficiently okay as it is
> >   •  Include a hash of the access token in the DPoP proof (when an 
> > access token is present)
> > 
> > Going with #2 would mean the draft would also have to define how the 
> > hashing is done and deal with or at least speak to algorithm agility. 
> > Options (that I can think of) include:
> >   • 2a) Use the at_hash claim defined in OIDC core 
> > https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken. Using 
> > something that already exists is appealing

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Torsten Lodderstedt]

Hi, 

I'm failing to understand why binding the proof to the access token ensures 
freshness of the proof. I would rather think if the client is forced to create 
proofs with a reasonable short lifetime, chances for replay could be reduced. 

Beside that as far as I remember the primary replay counter measure is the 
inclusion of the endpoint URL and HTTP method in the proof, since it reduces 
the attack surface to a particular URL. So in the context of freshness, we are 
talking about using the same proof with the same URL again. 

best regards,
Torsten. 

> Am 03.12.2020 um 10:20 schrieb Filip Skokan :
> 
> Hi Brian, everyone,
> 
> While the attack vector allows direct use, there is the option where a 
> smarter attacker will not abuse the gained artifacts straight away. Think 
> public client browser scenario with the non-extractable private key stored in 
> IndexedDB (the only place to persist them really), they wouldn't use the 
> tokens but instead, exfiltrate them, together with a bunch of pre-generated 
> DPoP proofs. They'll get the refresh token and a bunch of DPoP proofs for 
> both the RS and AS. With those they'll be able to get a fresh AT and use it 
> with pre-generated Proofs after the end-user leaves the site. No available 
> protection (e.g. RT already rotated) will be able to kick in until the 
> end-user opens the page again.
> 
> OTOH with a hash of the AT in the Proof only direct use remains.
> 
> If what I describe above is something we don't want to deal with because of 
> direct use already allowing access to protected resources, it's sufficiently 
> okay as is (option #1). However, if this scenario, one allowing prolonged 
> access to protected resources, is not acceptable, it's option #2.
> 
> Ad #2a vs #2b vs #2c. My pre-emptive answer is #2a, simply because we already 
> have the tools needed to generate and validate these hashes. But further 
> thinking about it, it would feel awkward if this JWS algorithm driven at_hash 
> digest selection wouldn't get stretched to the confirmations, when this are 
> placed in a JWT access token, cool - we can do that, but when these are put 
> in a basic token introspection response it's unfortunately not an option. So, 
> #2b (just use sha-256 just like the confirmations do).
> 
> Best,
> Filip
> 
> 
> On Wed, 2 Dec 2020 at 21:50, Brian Campbell 
>  wrote:
> There were a few items discussed somewhat during the recent interim that I 
> committed to bringing back to the list. The slide below (also available as 
> slide #17 from the interim presentation) is the first one of them, which is 
> difficult to summarize but kinda boils down to how much assurance there is 
> that the DPoP proof was 'freshly' created and that can dovetail into the 
> question of whether the token is covered by the signature of the proof. 
> There are many directions a "resolution" here could go but my sense of the 
> room during the meeting was that the contending options were:
>   •  It's sufficiently okay as it is
>   •  Include a hash of the access token in the DPoP proof (when an access 
> token is present)
> 
> Going with #2 would mean the draft would also have to define how the hashing 
> is done and deal with or at least speak to algorithm agility. Options (that I 
> can think of) include:
>   • 2a) Use the at_hash claim defined in OIDC core 
> https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken. Using 
> something that already exists is appealing. But its hash alg selection 
> routine can be a bit of a pain. And the algorithm agility based on the 
> signature that it's supposed to provide hasn't worked out as well as hoped in 
> practice for "new" JWS signatures 
> https://bitbucket.org/openid/connect/issues/1125/_hash-algorithm-for-eddsa-id-tokens
>   • 2b) Define a new claim ("ah", "ath", "atd", "ad" or something like 
> that maybe) and just use SHA-256. Explain why it's good enough for now and 
> the foreseeable future. Also include some text about introducing a new claim 
> in the future if/when SHA-256 proves to be insufficient. Note that this is 
> effectively the same as how the confirmation claim value is currently defined 
> in this document and in RFC8705.
>   • 2c) Define a new claim with its own hash algorithm agility scheme 
> (likely similar to how the Digest header value or Subresource Integrity 
> string is done).
> 
> I'm requesting that interested WG participants indicate their preference for 
> #1 or #2. And among a, b, and c, if the latter. 
> 
> I also acknowledge that an ECDH approach could/would ameliorate the issues in 
> a fundamentally different way. But that would be a distinct protocol. If 
> there's interest in pursuing the ECDH idea, I'm certainly open to it and even 
> willing to work on it. But as a separate effort and not at the expense of 
> derailing DPoP in its general current form. 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the 

Re: [OAUTH-WG] PAR error for redirect URI?

[Torsten Lodderstedt]

> Am 03.12.2020 um 09:56 schrieb Filip Skokan :
> 
> There are several documents already mentioning "invalid_redirect_uri" as an 
> error code, specifically RFC7519 and OpenID Connect Dynamic Client 
> Registration 1.0. But these don't register it in the IANA OAuth Extensions 
> Error Registry, presumably because they're neither for the authorization or 
> token endpoints.
> 
> While I think it'd be great if we had this error code registered, I also 
> worry that its registration could confuse implementers to think it's okay to 
> return it from the authorization endpoint.

I understand your concern. On the other hand, registering the error code is in 
my opinion the proper way forward. The registration is scoped to a usage 
location, should be pushed authorization endpoint then, and RFC6749 gives clear 
guidance on how to treat errors related to the redirect URI at the 
authorization endpoint. 

"If the request fails due to a missing, invalid, or mismatching
   redirection URI, … authorization server ... MUST NOT automatically redirect 
the user-agent to the
   invalid redirection URI."

I think if an implementor ignores this, it will ignore any advise.

best regards,
Torsten. 

> 
> Best,
> Filip
> 
> 
> On Thu, 3 Dec 2020 at 00:29, Brian Campbell 
>  wrote:
> During the course of a recent OIDF FAPI WG discussion (the FAPI profiles use 
> PAR for authz requests) on this issue it was noted that there's no specific 
> error code for problems with the redirect_uri (the example in 
> https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3 even 
> shows a general error code with mention of the redirect_uri not being valid 
> in the error description). Some folks on that call thought it would be 
> worthwhile to have a more specific error code for an invalid redirect_uri and 
> I reluctantly took an action item to raise the issue here. At the time I'd 
> forgotten that PAR had already passed WGLC. But it's been sitting idle while 
> awaiting the shepherd writeup since mid September so it's maybe realistic to 
> think the window for a small change is still open.
> 
> Presumably nothing like an "invalid_redirect_uri" error code was defined in 
> RFC 6749 because that class of errors could not be returned to the client via 
> redirection. But the data flow in PAR would allow for a 
> "invalid_redirect_uri" so it's not an unreasonable thing to do. 
> 
> As I write this message, however, I'm not personally convinced that it's 
> worth making a change to PAR at this point. But I did say I'd bring the 
> question up in the WG list and I'm just trying to be true to my word. So here 
> it is. Please weigh in, if you have opinions on the matter. 
> 
> 
> 
> 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=160759062900=AOvVaw3aW1gdv4EEiLmNYzlsJj-A

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

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-rar-03.txt

[Torsten Lodderstedt]

Hi all, 

I just published a new revision of draft-ietf-oauth-rar. This revision focuses 
on clarifications regarding the processing of RAR-based requests. 

Here is the list of changes:

• Added section about enrichment of authorization details objects by 
the AS
• Clarified processing of unknown authorization details parameters
• clarified dependencies between resource and authorization_details 
parameters
• Updated references to current revisions or RFC numbers

best regards,
Torsten. 

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-oauth-rar-03.txt
> Date: 18. October 2020 at 18:17:55 CEST
> To: "Brian Campbell" , "Torsten Lodderstedt" 
> , "Justin Richer" 
> 
> 
> A new version of I-D, draft-ietf-oauth-rar-03.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name: draft-ietf-oauth-rar
> Revision: 03
> Title:OAuth 2.0 Rich Authorization Requests
> Document date:2020-10-18
> Group:oauth
> Pages:35
> URL:https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> Html:   https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.html
> Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-rar-03
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-03
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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

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

[Torsten Lodderstedt]

Hi all, 

I just published a new revision of draft-ietf-oauth-jwt-introspection-response. 

Here are the changes from the history section: 

* added requirement to authenticate RS if privacy sensitive data is
  released
* reworked text on claims from different registries
* added forward reference to privacy considerations to 
section 5
* added text in privacy considerations regarding client/user
  tracking

Thanks for the review comments and change proposals.

best regards,
Torsten. 

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: [OAUTH-WG] I-D Action: 
> draft-ietf-oauth-jwt-introspection-response-10.txt
> Date: 18. October 2020 at 18:05:43 CEST
> To: 
> Cc: oauth@ietf.org
> Reply-To: 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-10.txt
>   Pages   : 20
>   Date: 2020-10-18
> 
> Abstract:
>   This specification proposes an additional JSON Web Token (JWT)
>   secured 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-10
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-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

Re: [OAUTH-WG] Implementation questions around refresh token rotation

[Torsten Lodderstedt]

Out of curiosity: Have you seen this in practice? I’m asking since most/all 
refresh token implementations I have seen are handles. Just rotating for 
consistency makes especially the live of server based clients harder as they 
need to propagate such a change through the cluster.

> Am 12.10.2020 um 11:54 schrieb David Waite 
> :
> 
> An AS may decide refresh token rotation is useful for other reasons (such as 
> if the token is an encrypted value and the AS cluster does key rotation), or 
> may decide to rotate all tokens for consistency.
> 
> Eventually best practices may indicate sender constrained tokens for public 
> clients. At that point, refresh rotation may not be security practice but 
> could still be something an AS does as part of its own design. And an AS may 
> elect to do this often so that clients fail (and correct their logic) faster.
> 
> -DW
> 
>>> On Oct 12, 2020, at 03:15, Torsten Lodderstedt 
>>>  wrote:
>>> 
>>> 
>>>> Am 12.10.2020 um 09:04 schrieb Dave Tonge :
>>>> 
>>> 
>>> Hi Neil
>>> 
>>>  > refresh token rotation is better thought of as providing protection 
>>> against insecure token storage on the client
>>> 
>>> I agree with your reasoning - and that was more the intent of what I said. 
>>> We've seen refresh token rotation used for confidential clients that have 
>>> secure storage (i.e. are run in a data center not on a mobile device) and 
>>> it has caused problems with zero additional security benefits. 
>> 
>> Those are good examples of why refresh token rotation should not be used if 
>> there are better ways available to protect refresh tokens from replay. 
>> Client authentication or sender constrained refresh tokens are the better 
>> choice.
> 
> ___
> 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] Implementation questions around refresh token rotation

[Torsten Lodderstedt]

> Am 12.10.2020 um 09:04 schrieb Dave Tonge :
> 
> 
> Hi Neil
> 
>  > refresh token rotation is better thought of as providing protection 
> against insecure token storage on the client
> 
> I agree with your reasoning - and that was more the intent of what I said. 
> We've seen refresh token rotation used for confidential clients that have 
> secure storage (i.e. are run in a data center not on a mobile device) and it 
> has caused problems with zero additional security benefits. 

Those are good examples of why refresh token rotation should not be used if 
there are better ways available to protect refresh tokens from replay. Client 
authentication or sender constrained refresh tokens are the better choice.

> 
> Dave
> 
> 
>> On Mon, 12 Oct 2020 at 08:57, Neil Madden  wrote:
>> I’m not sure I agree with this advice. Singling out private_key_jwt and 
>> tls_client_auth suggests that the problem is an attacker being able to 
>> eavesdrop on the refresh request itself and then replay it. But if they are 
>> able to do that then they can instead just steal the access tokens from the 
>> response.
>> 
>> I think refresh token rotation is better thought of as providing protection 
>> against insecure token storage on the client (e.g. in browser localStorage). 
>> Both public and confidential clients are capable of creating secure 
>> connections with TLS, but we assume that confidential clients (regardless of 
>> auth mechanism) have access to secure storage - otherwise they shouldn’t be 
>> confidential clients in the first place.
>> 
>> I think the same reasoning applies here too - if a client has insecure 
>> storage then an attacker could just steal the access tokens instead. But I 
>> think the difference is that an attacker is more likely to gain temporary 
>> access to local storage (e.g. when the user goes to the bathroom and leaves 
>> their device unlocked) than they are to gain temporary access to eavesdrop 
>> on a connection. The kind of vulnerabilities that allow eavesdropping tend 
>> to be repeatable so the attacker doesn’t need to steal a refresh token to 
>> ensure ongoing access, they can just steal the access tokens every time the 
>> client refreshes.
>> 
>> That said, there are lots of vulnerabilities that would give an attacker 
>> repeatable access to the client’s local storage - e.g. XSS - so refresh 
>> token rotation only catches a subset of possible attacks.
>> 
>> — Neil
>> 
>>> On 12 Oct 2020, at 05:43, Dave Tonge  wrote:
>>> 
>>> > Our goal is to prevent cases where we lose the ability to Refresh a Token 
>>> > due to transient issues (which have run the gamut from network problems 
>>> > to bad software updates on the AS side).
>>> 
>>> We've seen this issue quite a bit and it's very frustrating. I would 
>>> suggest that refresh token rotation is not used for confidential clients 
>>> that authenticate with private_key_jwt or tls_client_auth. 
>>> 
 On Wed, 7 Oct 2020 at 00:57, Jeff Craig 
  wrote:
 My experience is more from the Client side of the equation on this 
 problem, but I do have some thoughts. Our goal is to prevent cases where 
 we lose the ability to Refresh a Token due to transient issues (which have 
 run the gamut from network problems to bad software updates on the AS 
 side). Our use case also does all token handling server-side, so our 
 threat model is not the same as the mobile application you described. 
 There is a clear tradeoff in reducing user friction with additional 
 authorization events, and securing access.
 
 The recommendation my team typically gives people building Authorization 
 Servers with Refresh Token Rotation is to keep the old refresh token until 
 they see the new one (which means that there are generally two refresh 
 tokens valid at any point in time, an unfortunate trade-off). A more 
 difficult, but potentially plausible implementation would be to hold onto 
 the older Refresh Token until the newly issued Access Token is used (thus 
 implying the refresh was successful on both sides).
 
 We aren't trying to protect against multiple in-flight refreshes though 
 (we've done a LOT of work to attempt to remove that possibility in a 
 globally consistent manner), we're trying to protect against a network 
 interruption that prevents the first use of R1, so our assumption is that 
 R2.1 was completely lost, and only R2.2 matters moving forward. Meaning: 
 R1 is sent, A/R2.1 is dropped in flight, R1 is sent again, A/R2.2 is 
 returned and stored. Since R1 was seen a second time, we recommend that 
 R2.1 be ignored in future. Next refresh will use R2.2, at which point R1 
 should never be seen again.
 
 The biggest issue that I see with a time-based grace period is that for 
 many offline tasks, a single refresh failure may be ignored by the client, 
 and it could be hours before the second refresh attempt 

Re: [OAUTH-WG] Implementation questions around refresh token rotation

[Torsten Lodderstedt]

> Am 07.10.2020 um 09:20 schrieb Neil Madden :
> 
> 
> 
>>> On 6 Oct 2020, at 23:05, Aaron Parecki  wrote:
>>> 
>> 
>> Hi all, I have a couple questions for those of you who have implemented 
>> refresh token rotation...
>> 
>> Have you included the option of a grace period on refresh token use, 
>> allowing multiple uses within some time window? I'm wondering because a 
>> grace period where a refresh token may be used more than once would work 
>> around the problem that has been brought up, of a mobile app accidentally 
>> using a refresh token more than once during normal operation because 
>> different threads are unable to coordinate between themselves. However that 
>> also kind of defeats the purpose since attacks within that grace period 
>> would be hard to detect. I'm looking for an idea of where people have landed 
>> on that issue in practice.
> 
> Right. We’ve avoided adding a grace period for this reason. An attacker in a 
> position to steal a refresh token is also presumably in a position to see 
> when the legitimate client uses it and then sneak in just afterwards within 
> the grace period. You could maybe only allow grace period refreshes from the 
> same IP address but I’m not sure that would always hold in the flaky mobile 
> network scenarios (eg refresh fails on 2G due to disconnect then client 
> switches to Wifi hotspot and retries). 

We did not implement a grace period for the same reason. Refresh token rotation 
is a countermeasure against refresh token theft and replay for public client. A 
grace period to some degree limits it effectiveness against exactly this attack.

best regards,
Torsten.

> 
>> If you have implemented a grace period, then how do you handle expiring the 
>> additional refresh tokens that have been granted? For example, if RT "R1" is 
>> used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and 
>> "R1.2", what happens if "R1.2" is then later used? Would you invalidate 
>> "R1.1" at that point? If so, why, and if not, why not?
>> 
>> It would be most interesting to hear practical experience from people who 
>> have already built refresh token rotation into a system.
>> 
>> Thanks!
>> 
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>> 
>> ___
>> 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] JWT access tokens and the revocation endpoint

[Torsten Lodderstedt]

> On 7. Oct 2020, at 19:45, Seán Kelleher  wrote:
> 
> Hi all,
> 
> Long time lurker, first time poster, glad to be finally getting involved!
> 
> In terms of weighing in on the revocation practice, I don't think this 
> document needs to address it as JWT ATs don't seem to require special 
> handling in this case. I think a general coverage of approaches to token 
> revocation would be more appropriate in a BCP.
> 
> One thing I'm unsure of when reading this is how a RS can depend on an AS to 
> give it a JWT AT. Due to the opaque nature of ATs, it seems natural that an 
> AS can change the AT profile it uses at its own discretion, but there's no 
> negotiation or parameter that can force an AS to return a JWT AT, with the 
> potential for breakages. Do the RS and AS agree on the profile ahead of time? 
>  

yes, they do. Basically, the AS is acting on behalf of the RS and centralises 
the authorization work. 

> Perhaps this is specified in a separate document, but I think the topic of 
> profile negotiation should be covered in this document, even at a high level, 
> or reference to more detailed coverage.

Good point. I think this is a general assumption in OAuth. Should probably go 
into OAuth 2.1.

> 
> A few other notes on the document itself:
>   • Section 2.1: Is there precedence of "application/at+jwt" being used 
> in the wild that prevents the SHOULD from being a MUST?
>   • Figure 1: Nitpick: An `&` that looks like it should prefix `state` is 
> on the preceding line.
>   • Figure 2: The example `typ` is `at+JWT`, should this be `at+jwt`?
>   • Section 4: This is a personal opinion, but I'd recommend moving the 
> step concerning `aud` validation to the top of the list, for focus. This is 
> because, having personally taken more than a little while to figure out the 
> difference between access tokens and ID tokens, I see the risk of cross-JWT 
> confusion as very relevant. I think the necessity of the other steps are a 
> bit more obvious.
> Thanks!
> 
> Kind regards,
> 
> Seán.
> 
> On Tue, 6 Oct 2020 at 22:53,  
> wrote:
> Hi Andrii,
> 
> Thanks for the thoughtful comments! Here’s my 2 c.
> 
>  
> 
> On the proposed language: given that the JWT AT profile is just providing 
> more details on the content of an AT, making JWT ATs a proper subset of all 
> ATs, readers should have no reason to believe that introspection or any other 
> existing spec discussing AT behavior should operate differently. That 
> assumption holds for everything across the board, hence it would be a bit odd 
> to call out this particular case. On the userinfo case, I would find it even 
> more left field to say anything about it.
> If we do reach a consensus on specific revocation practices that apply to JWT 
> ATs specifically, and we conclude that they should live in this document, I 
> will be happy to add language accordingly.
> 
>  
> 
> On the AJWT: I hear you on the dissonance that JWT AT carries, but I am very 
> hesitant to introduce new acronyms to an already crowded/impenetrable domain.
> JWT access token might not roll off the tongue, but at this point ‘JWT’ is 
> nearly a proprietary eponym and the expression “JWT token” is extraordinarily 
> common in literature, a quick google query will give you the full measure of 
> the phenomenon, hence I think we’ll be OK with the current form.
> 
> Cheers,
> 
> V.
> 
>  
> 
> From: Andrii Deinega  
> Sent: Tuesday, October 6, 2020 2:25 PM
> To: vittorio.berto...@auth0.com; oauth@ietf.org
> Cc: Jim Manico ; Nicolas Mora 
> Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
> 
>  
> 
> Vittorio and WG,
> 
>  
> 
> Would it be possible to include something like the following to 
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10
> 
> 
> In case the authorization server exposes the introspection, revocation, and 
> OpenID Connect userinfo endpoints they MUST act in the same way as it happens 
> with a regular access token. That allows the AS to change the type of an 
> access token on the fly and that won’t lead to interoperate issues. Plus, the 
> consumers of these endpoints use them regardless of the type of access token.
> 
>  
> 
> The way how the AS can notify RSs that the token revocation event happened 
> (if it decides to do so) is completely left to implementers.
> 
>  
> 
> ?
> 
>  
> 
> Another minor editorial thing from me is it would possible to change and 
> refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the 
> token word twice.
> 
>  
> 
> Regards,
> 
> Andrii
> 
>  
> 
> On Tue, Oct 6, 2020 at 2:22 PM  
> wrote:
> 
> Hey Jim, regarding
> > Every logout event should trigger token revocation
> That isn’t necessarily the case. An access token represents the ability of a 
> client to access a given resource; the fact that it requires an 
> authentication transaction/session establishment to be issued to the client 
> does not mean that the AT lifetime is tied to the lifetime of 

Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

[Torsten Lodderstedt]

Great! Just drop me an email if you need support.

> On 4. Sep 2020, at 15:07, Karsten Meyer zu Selhausen 
>  wrote:
> 
> I am fairly new to this working group (and the IETF in general), so I will 
> probably need some guidance, but I would be happy to help better defining 
> mix-up preventions. I will start to work on an ID.
> 
> Best regards,
> Karsten
> 
> On 29.08.2020 14:34, Torsten Lodderstedt wrote:
>>> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen 
>>> 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I think we all agree that proper countermeasures of mix-up attacks should 
>>> definitely be part of the BCP and 2.1 due to the severe impact successful 
>>> mix-up attacks have.
>>> Theoretically speaking every client which supports multiple AS is 
>>> potentially vulnerable to mix-up attacks. While in practice it might seem 
>>> unlikely it is possible that one of the honest AS the client supports gets 
>>> compromised and can be utilized for a mix-up attack. 
>>> 
>>> In a previous thread of last November (
>>> https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/
>>> ) I discussed why “use distinct redirect URIs for each AS” is not an 
>>> effective countermeasure against mix-up attacks (if dynamic client 
>>> registration is used). I would argue that this is especially important for 
>>> mobile applications, SPAs, and other native applications because it is very 
>>> common for them to use dynamic client registration. Many iOS applications 
>>> now must support multiple AS since Apple forces the support for “Sign in 
>>> with Apple” if any single sign-on provider is supported. This policy makes 
>>> mix-up attacks applicable.
>>> 
>>> I fully agree with Daniel, Brian, and Mike that it is important to define 
>>> and register the “iss” parameter properly to ensure that both clients and 
>>> AS understand and use it in the correct way. I understand that OAuth 2.1 is 
>>> not meant to introduce and define new parameters but I strongly suggest 
>>> that the “iss” parameter should be introduced and defined elsewhere so that 
>>> it can be natively included in 2.1. In other words the “iss” parameter 
>>> should be integrated in 2.1 the same way PKCE is: the initial definition of 
>>> the parameter(s) is in another document (RFC 7636 in the case of PKCE) and 
>>> then included in 2.1.
>>> 
>>> What do you think would be the best place to define and register the “iss” 
>>> parameter? Would it be worthwhile to reactivate and update 
>>> “draft-ietf-oauth-mix-up-mitigation”?
>>> 
>> That’s a decision of the authors. Alternatively, a new small draft 
>> (referring to the BCP’s attack description) should do the job as well. Mind 
>> to write an ID? :-)
>> 
>> 
>>> Best regards,
>>> 
>>> Karsten
>>> 
>>> 
>>> 
>>> On 18.06.2020 22:49, Mike Jones wrote:
>>> 
>>>> I support documenting the use of the issuer to mitigate mix-up attacks.  
>>>> Note that while issuer was first defined by OpenID Connect, it became art 
>>>> of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata.
>>>>  
>>>>-- Mike
>>>>  
>>>> From: OAuth 
>>>> 
>>>>  On Behalf Of Brian Campbell
>>>> Sent: Thursday, June 18, 2020 1:32 PM
>>>> To: Daniel Fett 
>>>> 
>>>> 
>>>> Cc: oauth 
>>>> 
>>>> 
>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited
>>>>  
>>>> In my (probably simplistic) understanding of things, the root underlying 
>>>> issue that allows for mix-up in its variations is the lack of anything 
>>>> identifying the AS in the authorization response. Following from that, 
>>>> introducing and using an `iss` authorization response parameter has always 
>>>> seemed like the most straightforward approach for mitigating the issue 
>>>> (which was part of the draft-ietf-oauth-mix-up-mitigation but other 
>>>> parameters were also included and, for reasons I'm not sure about, 
>>>> interest in that work faded in favor of telling clients to use per AS 
>>>> redirect URIs) . Though for the `iss` authorization response parameter to 
>>>> be effective, all parties involved need to know about it and act on it. So 
>>>> I think it'd ne

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

it’s a decent view on the 
> “why".
> 
> The aibility to set up transaction specific redirect URIs is also useful in 
> situations where client ids and correspoding credentials and policies are 
> managed by a trusted 3rd party, e.g. via client certifiates containing client 
> permissions. Such an externally managed client could interact with an AS 
> trusting the respective 3rd party without the need for an additional 
> registration step.
> 
>  — Justin
> 
>> On Sep 1, 2020, at 11:05 PM, Takahiko Kawasaki  wrote:
>> 
>> Under existing specifications (RFC 6749, OIDC Core 1.0 and FAPI), a client 
>> can choose an arbitrary redirect_uri without registering it only when all 
>> the following conditions are satisfied.
>> 
>> 1. The client type of the client is "confidential". (RFC 6749 Section 
>> 3.1.2.2 requires that public clients register redirect URIs.)
>> 2. The flow is not "implicit". (RFC 6749 Section 3.1.2.2 requires that 
>> confidential clients utilizing the implicit grant type register redirect 
>> URIs.)
>> 3. The authorization request is not an OIDC request. (OIDC Core 1.0 Section 
>> 3.1.2.1 requires that redirect_uri match a pre-registered one.)
>> 4. The authorization request is not a FAPI request. (FAPI Part 1 Section 
>> 5.2.2 Clause 8 requires that redirect URIs be pre-registered.)
>> 
>> In short, under existing specifications, pure RFC-6749 
>> authorization-code-flow requests from confidential clients can choose an 
>> arbitrary redirect_uri without registering it. Once OIDC or FAPI is used, 
>> existing specifications require pre-registration of redirect URIs. I'm not 
>> sure but if PAR's "redirect_uri Management" is going to introduce rules that 
>> conflict with existing specifications, it is better to list the conflicts 
>> explicitly in the section.
>> 
>> Best Regards,
>> Takahiko Kawasaki
>> 
>> 
>> On Wed, Sep 2, 2020 at 3:48 AM Torsten Lodderstedt 
>>  wrote:
>> Here is my proposal for the new section:
>> 
>> 2.4. redirect_uri Management
>> 
>> The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 
>> [I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri 
>> parameter against the set of redirect URIs previously established for a 
>> particular client. This is a means to early detect attempts to impersonate a 
>> client and prevent token leakage and open redirection. As a downside, it 
>> makes client management more complex since the redirect URI is typically the 
>> most volatile part of a client policy.
>> 
>> This requirement MAY be relaxed by the AS, if a confidential client uses 
>> pushed authorization requests since the AS authenticates the client before 
>> the authorization process starts and that way ensures it interacts with the 
>> legit client. The AS MAY allow such clients to specify redirect_uri values 
>> not previously registered with the AS. This will give the client more 
>> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes 
>> client management much easier. It is at the discretion of the AS to apply 
>> restriction on redirect_uri values, e.g. the AS MAY require a certain URI 
>> prefix or allow only a query parameter to vary at runtime.
>> 
>> Note: The aibility to set up transaction specific redirect URIs is also 
>> useful in situations where client ids and correspoding credentials and 
>> policies are managed by a trusted 3rd party, e.g. via client certifiates 
>> containing client permissions. Such an externally managed client could 
>> interact with an AS trusting the respective 3rd party without the need for 
>> an additional registration step.
>> 
>> > On 29. Aug 2020, at 17:22, Justin Richer  wrote:
>> > 
>> > I completely agree with the utility of the function in question here and 
>> > it needs to be included. I’m in favor of creating a dedicated section for 
>> > redirect_uri management, so that we can explain exactly how and why to 
>> > relax the requirement from core OAuth. In addition, I think we want to 
>> > discuss that the AS might have its own restrictions on which redirect URIs 
>> > an authenticated client might be able to use. For example, registering a 
>> > client with a Redirect URI prefix, or allowing only a query parameter to 
>> > vary at runtime. All of these can be enforced in PAR because the client is 
>> > presenting its authentication, as you point out, so the AS can determine 
>> > which policies should apply.
>> > 
>> > 

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

yes.

> On 3. Sep 2020, at 13:33, Brian Campbell  wrote:
> 
> Do you mean just putting the "Note:" back in front of it? WFM. 
> 
> 
> 
> On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt  
> wrote:
> Thanks Brian!
> 
> I suggest to put a Note: in front of the last paragraph to indicate it is 
> additional infomercial.
> 
> WDYT?
> 
> > Am 03.09.2020 um 02:29 schrieb Justin Richer :
> > 
> > Nice work, Brian. Looks good to me! 
> > 
> > From: Brian Campbell [bcampb...@pingidentity.com]
> > Sent: Wednesday, September 2, 2020 3:41 PM
> > To: Justin Richer
> > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
> > Subject: Re: [OAUTH-WG] WGLC Review of PAR
> > 
> > Thanks Torsten, Taka, and Justin,
> > 
> > I took the revised text from Justin and tweaked it with some typo cleanup 
> > and minor adjustments to make what is hopefully a final proposal below. I 
> > had a similar feeling about the last paragraph not really fitting but don't 
> > have a better location to suggest so am just leaving it.
> > 
> > 2.4. Management of Client Redirect URIs
> > 
> > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> > values in certain circumstances, or for the authorization server to apply 
> > its own matching semantics to the redirect_uri value presented by the 
> > client at the authorization endpoint, the OAuth Security BCP 
> > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> > require an authorization server exactly match the redirect_uri parameter 
> > against the set of redirect URIs previously established for a particular 
> > client. This is a means for early detection of client impersonation 
> > attempts and prevents token leakage and open redirection. As a downside, 
> > this can make client management more cumbersome since the redirect URI is 
> > typically the most volatile part of a client policy.
> > 
> > The exact matching requirement MAY be relaxed by the authorization server 
> > for a confidential client using pushed authorization requests since the 
> > authorization server authenticates the client before the authorization 
> > process starts and thus ensures it is interacting with the legitimate 
> > client. The authorization server MAY allow such clients to specify 
> > redirect_uri values that were not previously registered with the 
> > authorization server. This will give the client more flexibility (e.g. to 
> > mint distinct redirect URI values per authorization server at runtime) and 
> > can simplify client management. It is at the discretion of the 
> > authorization server to apply restrictions on supplied redirect_uri values, 
> > e.g. the authorization server MAY require a certain URI prefix or allow 
> > only a query parameter to vary at runtime.
> > 
> > The ability to set up transaction specific redirect URIs is also useful in 
> > situations where client ids and corresponding credentials and policies are 
> > managed by a trusted 3rd party, e.g. via client certificates containing 
> > client permissions. Such an externally managed client could interact with 
> > an authorization server trusting the respective 3rd party without the need 
> > for an additional registration step.
> > 
> > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 
> > mailto:jric...@mit.edu>> wrote:
> > The real conflict here is with the BCP and 2.1, both of which adopt the 
> > stricter matching semantics for redirect URIs than 6749 does on its own. 
> > This section would be needed to clarify how they relate to each other. That 
> > said, I think adding some of Taka’s observations to Torsten’s text wouldn’t 
> > hurt:
> > 
> > 2.4. Management of redirect_uri
> > 
> > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> > values in certain circumstances, or for the AS to apply its own matching 
> > semantics to the redirect_uri value presented by the client at the 
> > authorization endpoint, the OAuth Security BCP 
> > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> > require an AS to excactly match the redirect_uri parameter against the set 
> > of redirect URIs previously established for a particular client. This is a 
> > means to early detect attempts to impersonate a client and prevent token 
> > leakage and open redirection. As a downside, it makes client management 
> > more complex since the redirect URI is typically the most volatile part of 
> > a client policy.
> 

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

Thanks Brian!

I suggest to put a Note: in front of the last paragraph to indicate it is 
additional infomercial.

WDYT?

> Am 03.09.2020 um 02:29 schrieb Justin Richer :
> 
> Nice work, Brian. Looks good to me! 
> 
> From: Brian Campbell [bcampb...@pingidentity.com]
> Sent: Wednesday, September 2, 2020 3:41 PM
> To: Justin Richer
> Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
> Subject: Re: [OAUTH-WG] WGLC Review of PAR
> 
> Thanks Torsten, Taka, and Justin,
> 
> I took the revised text from Justin and tweaked it with some typo cleanup and 
> minor adjustments to make what is hopefully a final proposal below. I had a 
> similar feeling about the last paragraph not really fitting but don't have a 
> better location to suggest so am just leaving it.
> 
> 2.4. Management of Client Redirect URIs
> 
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> values in certain circumstances, or for the authorization server to apply its 
> own matching semantics to the redirect_uri value presented by the client at 
> the authorization endpoint, the OAuth Security BCP 
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> require an authorization server exactly match the redirect_uri parameter 
> against the set of redirect URIs previously established for a particular 
> client. This is a means for early detection of client impersonation attempts 
> and prevents token leakage and open redirection. As a downside, this can make 
> client management more cumbersome since the redirect URI is typically the 
> most volatile part of a client policy.
> 
> The exact matching requirement MAY be relaxed by the authorization server for 
> a confidential client using pushed authorization requests since the 
> authorization server authenticates the client before the authorization 
> process starts and thus ensures it is interacting with the legitimate client. 
> The authorization server MAY allow such clients to specify redirect_uri 
> values that were not previously registered with the authorization server. 
> This will give the client more flexibility (e.g. to mint distinct redirect 
> URI values per authorization server at runtime) and can simplify client 
> management. It is at the discretion of the authorization server to apply 
> restrictions on supplied redirect_uri values, e.g. the authorization server 
> MAY require a certain URI prefix or allow only a query parameter to vary at 
> runtime.
> 
> The ability to set up transaction specific redirect URIs is also useful in 
> situations where client ids and corresponding credentials and policies are 
> managed by a trusted 3rd party, e.g. via client certificates containing 
> client permissions. Such an externally managed client could interact with an 
> authorization server trusting the respective 3rd party without the need for 
> an additional registration step.
> 
> On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 
> mailto:jric...@mit.edu>> wrote:
> The real conflict here is with the BCP and 2.1, both of which adopt the 
> stricter matching semantics for redirect URIs than 6749 does on its own. This 
> section would be needed to clarify how they relate to each other. That said, 
> I think adding some of Taka’s observations to Torsten’s text wouldn’t hurt:
> 
> 2.4. Management of redirect_uri
> 
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> values in certain circumstances, or for the AS to apply its own matching 
> semantics to the redirect_uri value presented by the client at the 
> authorization endpoint, the OAuth Security BCP 
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> require an AS to excactly match the redirect_uri parameter against the set of 
> redirect URIs previously established for a particular client. This is a means 
> to early detect attempts to impersonate a client and prevent token leakage 
> and open redirection. As a downside, it makes client management more complex 
> since the redirect URI is typically the most volatile part of a client policy.
> 
> This requirement MAY be relaxed by the AS if a confidential client uses 
> pushed authorization requests since the AS authenticates the client before 
> the authorization process starts and that way ensures it interacts with the 
> legit client. The AS MAY allow such clients to specify redirect_uri values 
> not previously registered with the AS. This will give the client more 
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes 
> client management much easier. It is at the discretion of the AS to apply 
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI 

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

> On 2. Sep 2020, at 05:58, William Denniss 
>  wrote:
> 
> +1 to drop the "third party", there are valid first party use-cases. 
> 
> On the subject, in first party cases the access may not be all that 
> "limited", I wonder if it should read more genericly "an application to 
> obtain access to an HTTP service"?

I suggest to stick with “limited” since privilege restriction is always a good 
idea. 

> 
> On Tue, Sep 1, 2020 at 5:20 PM Dima Postnikov  wrote:
> Good point Denis, thanks
> 
> The OAuth 2.1 authorization framework enables an third-party
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>
> third-party
>  application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in 
> RFC 6749.
> 
> And an additional section is required to describe scenarios where this 
> framework works well and scenarios when it doesn't.
> 
> On Wed, Sep 2, 2020 at 12:57 AM Denis  wrote:
> Hello Dima,
> 
> Not exactly. 
> 
> Change :
>  or by allowing the third-party application
> into:
> 
> or by allowing the application
> 
> Denis
> 
>> Thank everyone for your feedback.
>> 
>> So the abstract could look like this:
>> 
>> The OAuth 2.1 authorization framework enables an third-party
>>application to obtain limited access to an HTTP service, either on
>>behalf of a resource owner by orchestrating an approval interaction
>>between the resource owner and the HTTP service, or by allowing the
>>third-party application to obtain access on its own behalf.  This
>>specification replaces and obsoletes the OAuth 2.0 Authorization
>>Framework described in 
>> RFC 6749.
>> 
>> And an additional section is required to describe scenarios where this 
>> framework works well and scenarios when it doesn't.
>> 
>> On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki  wrote:
>> I agree. While the original motivations for OAuth were to support 
>> third-party apps, it's proven to be useful in many other kinds of situations 
>> as well, even when it's a "first-party" app but the OAuth server is operated 
>> by a different organization than the APIs. I don't think the abstract needs 
>> any qualification on this and would only confuse people further. Any 
>> clarifications of which situations are appropriate for using OAuth could be 
>> explored in a different section in the spec.
>> 
>> Aaron Parecki
>> 
>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
>>  wrote:
>> I agree. OAuth works for 3rd as well as 1st parties as well. 
>> 
>> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
>> > 
>> > Hi,
>> > 
>> > Can "third-party" term be removed from the specification?
>> > 
>> > The standard and associated best practices apply to other applications 
>> > that act on behalf of a resource owner, too (internal, "first-party" and 
>> > etc).
>> > 
>> > Regards,
>> > 
>> > Dima
>> > 
>> > The OAuth 2.1 authorization framework enables a third-party
>> > 
>> >application to obtain limited access to an HTTP service, either on
>> >behalf of a resource owner by orchestrating an approval interaction
>> >between the resource owner and the HTTP service, or by allowing the
>> >third-party application to obtain access on its own behalf.  This
>> >specification replaces and obsoletes the OAuth 2.0 Authorization
>> >Framework described in 
>> > RFC 6749.
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> ___
> 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] WGLC Review of PAR

[Torsten Lodderstedt]

Here is my proposal for the new section:

2.4. redirect_uri Management

The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 
[I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri 
parameter against the set of redirect URIs previously established for a 
particular client. This is a means to early detect attempts to impersonate a 
client and prevent token leakage and open redirection. As a downside, it makes 
client management more complex since the redirect URI is typically the most 
volatile part of a client policy.

This requirement MAY be relaxed by the AS, if a confidential client uses pushed 
authorization requests since the AS authenticates the client before the 
authorization process starts and that way ensures it interacts with the legit 
client. The AS MAY allow such clients to specify redirect_uri values not 
previously registered with the AS. This will give the client more flexibility 
(e.g. to mint AS-specific redirect URIs on the fly) and makes client management 
much easier. It is at the discretion of the AS to apply restriction on 
redirect_uri values, e.g. the AS MAY require a certain URI prefix or allow only 
a query parameter to vary at runtime.

Note: The aibility to set up transaction specific redirect URIs is also useful 
in situations where client ids and correspoding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certifiates containing client 
permissions. Such an externally managed client could interact with an AS 
trusting the respective 3rd party without the need for an additional 
registration step.

> On 29. Aug 2020, at 17:22, Justin Richer  wrote:
> 
> I completely agree with the utility of the function in question here and it 
> needs to be included. I’m in favor of creating a dedicated section for 
> redirect_uri management, so that we can explain exactly how and why to relax 
> the requirement from core OAuth. In addition, I think we want to discuss that 
> the AS might have its own restrictions on which redirect URIs an 
> authenticated client might be able to use. For example, registering a client 
> with a Redirect URI prefix, or allowing only a query parameter to vary at 
> runtime. All of these can be enforced in PAR because the client is presenting 
> its authentication, as you point out, so the AS can determine which policies 
> should apply.
> 
> — Justin
> 
>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
>> wrote:
>> 
>> 
>>> 
>>> 
>>>   ¶6: Does the AS really have "the ability to authenticate and authorize 
>>> clients”? I think what we mean here is "the ability to authenticate clients 
>>> and validate client requests”, but I’m not positive of the intent. 
>>> 
>>> I think the intent is that the AS can check whether a client is authorized 
>>> to make a particular authorization request (specific scopes, response type, 
>>> etc.). But checking authorization to request authorization is confusing 
>>> wording. I think your working is less confusing and still allows for the 
>>> intent. 
>>> 
>>> I'll let Torsten interject if he feels differently as I think he originally 
>>> wrote the text in question. 
>> 
>> that was the original intent. I think “validate" is fine. 
>> 
>>> 
>>> 
>>> 
>>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed 
>>> externally, the association with a set or pattern of allowed redirect URIs 
>>> is still important, and the AS will need to know what that is. I think this 
>>> example could lead an AS developer to (erroneously and dangerously) 
>>> conclude that they don’t have to check any other values in a request, 
>>> including scope and redirect URI. It’s important that DynReg doesn’t 
>>> alleviate that issue, but removal of DynReg doesn’t really change things in 
>>> that regard. Suggest removing example or reworking paragraph.
>>> 
>>> I'm going to have to defer to Torsten on this because, to be honest, I'm 
>>> not too sure about it myself. I tend to lean towards thinking the draft 
>>> would be better off without it. 
>>> 
>> 
>> In the traditional authorization flow, the redirect_uri serves as way to 
>> make sure the AS is really talking to the legit client and the allowed 
>> redirect_uri values are determined by the legit client at registration time 
>> (might be manually).
>> 
>> With PAR, we have a much stronger means to ensure the AS is talking to the 
>> legit client. That’s why I don’t see an issue with letting the client set a 
>> per transaction redirect_uri. This will give the client more flexibility 

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

I gone draft this section.

> Am 29.08.2020 um 17:22 schrieb Justin Richer :
> 
> I completely agree with the utility of the function in question here and it 
> needs to be included. I’m in favor of creating a dedicated section for 
> redirect_uri management, so that we can explain exactly how and why to relax 
> the requirement from core OAuth. In addition, I think we want to discuss that 
> the AS might have its own restrictions on which redirect URIs an 
> authenticated client might be able to use. For example, registering a client 
> with a Redirect URI prefix, or allowing only a query parameter to vary at 
> runtime. All of these can be enforced in PAR because the client is presenting 
> its authentication, as you point out, so the AS can determine which policies 
> should apply.
> 
> — Justin
> 
>>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> 
>>> 
>>> 
>>>   ¶6: Does the AS really have "the ability to authenticate and authorize 
>>> clients”? I think what we mean here is "the ability to authenticate clients 
>>> and validate client requests”, but I’m not positive of the intent. 
>>> 
>>> I think the intent is that the AS can check whether a client is authorized 
>>> to make a particular authorization request (specific scopes, response type, 
>>> etc.). But checking authorization to request authorization is confusing 
>>> wording. I think your working is less confusing and still allows for the 
>>> intent. 
>>> 
>>> I'll let Torsten interject if he feels differently as I think he originally 
>>> wrote the text in question. 
>> 
>> that was the original intent. I think “validate" is fine. 
>> 
>>> 
>>> 
>>> 
>>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed 
>>> externally, the association with a set or pattern of allowed redirect URIs 
>>> is still important, and the AS will need to know what that is. I think this 
>>> example could lead an AS developer to (erroneously and dangerously) 
>>> conclude that they don’t have to check any other values in a request, 
>>> including scope and redirect URI. It’s important that DynReg doesn’t 
>>> alleviate that issue, but removal of DynReg doesn’t really change things in 
>>> that regard. Suggest removing example or reworking paragraph.
>>> 
>>> I'm going to have to defer to Torsten on this because, to be honest, I'm 
>>> not too sure about it myself. I tend to lean towards thinking the draft 
>>> would be better off without it.
>>> 
>> 
>> In the traditional authorization flow, the redirect_uri serves as way to 
>> make sure the AS is really talking to the legit client and the allowed 
>> redirect_uri values are determined by the legit client at registration time 
>> (might be manually).
>> 
>> With PAR, we have a much stronger means to ensure the AS is talking to the 
>> legit client. That’s why I don’t see an issue with letting the client set a 
>> per transaction redirect_uri. This will give the client more flexibility 
>> (mint AS-specific redirect URIs on the fly) and makes client management much 
>> easier since redirect URIs are the most volatile part of a client policy. 
>> 
>> It also makes use of OAuth much easier in deployments where client 
>> identities are managed by external entities (even without any idea of 
>> OAuth). A prominent example is open banking in the EU (aka PSD2). The 
>> (technical) identity of any PSD2-licensed client is asserted by an eIDAS 
>> compliant CA in a special X.509 certificate. Those certificates contain the 
>> permissions (access to account information and/or payment initiation 
>> allowed) and the identity (member state specific). But they don’t contain 
>> OAuth policy values. Nevertheless, the regulation requires any financial 
>> institution in the EU to at runtime, without any registration, to accept and 
>> process calls from any licensed PSD2 clients.
>> 
>> There are two ways to cope with it in OAuth context:
>> a) use dynamic client registration with the X.509 cert as credential. 
>> Unfortunately, RFC 7591 does not support other client authentication means 
>> then an initial access token. Beside that, it would violate the text of the 
>> regulation. 
>> b) establish a redirect URL with every transaction. This is the recommended 
>> approach in at least one of the PSD2 specs.
>> 
>> PAR is a clean way to solve that problem. 
>> 
>> I don’t want this text to cause confusing. On the other hand this potential 
>> of PAR is way too important to not mention it at all. What about moving it 
>> into a special section "redirect_uri management”?
>> 
>>> 
>> 
> 


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

Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

[Torsten Lodderstedt]

> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen 
>  wrote:
> 
> Hi all,
> 
> I think we all agree that proper countermeasures of mix-up attacks should 
> definitely be part of the BCP and 2.1 due to the severe impact successful 
> mix-up attacks have.
> Theoretically speaking every client which supports multiple AS is potentially 
> vulnerable to mix-up attacks. While in practice it might seem unlikely it is 
> possible that one of the honest AS the client supports gets compromised and 
> can be utilized for a mix-up attack. 
> 
> In a previous thread of last November 
> (https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/) I 
> discussed why “use distinct redirect URIs for each AS” is not an effective 
> countermeasure against mix-up attacks (if dynamic client registration is 
> used). I would argue that this is especially important for mobile 
> applications, SPAs, and other native applications because it is very common 
> for them to use dynamic client registration. Many iOS applications now must 
> support multiple AS since Apple forces the support for “Sign in with Apple” 
> if any single sign-on provider is supported. This policy makes mix-up attacks 
> applicable.
> 
> I fully agree with Daniel, Brian, and Mike that it is important to define and 
> register the “iss” parameter properly to ensure that both clients and AS 
> understand and use it in the correct way. I understand that OAuth 2.1 is not 
> meant to introduce and define new parameters but I strongly suggest that the 
> “iss” parameter should be introduced and defined elsewhere so that it can be 
> natively included in 2.1. In other words the “iss” parameter should be 
> integrated in 2.1 the same way PKCE is: the initial definition of the 
> parameter(s) is in another document (RFC 7636 in the case of PKCE) and then 
> included in 2.1.
> 
> What do you think would be the best place to define and register the “iss” 
> parameter? Would it be worthwhile to reactivate and update 
> “draft-ietf-oauth-mix-up-mitigation”?

That’s a decision of the authors. Alternatively, a new small draft (referring 
to the BCP’s attack description) should do the job as well. Mind to write an 
ID? :-)

> 
> Best regards,
> 
> Karsten
> 
> 
> 
> On 18.06.2020 22:49, Mike Jones wrote:
>> I support documenting the use of the issuer to mitigate mix-up attacks.  
>> Note that while issuer was first defined by OpenID Connect, it became art of 
>> OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata.
>>  
>>-- Mike
>>  
>> From: OAuth  On Behalf Of Brian Campbell
>> Sent: Thursday, June 18, 2020 1:32 PM
>> To: Daniel Fett 
>> Cc: oauth 
>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited
>>  
>> In my (probably simplistic) understanding of things, the root underlying 
>> issue that allows for mix-up in its variations is the lack of anything 
>> identifying the AS in the authorization response. Following from that, 
>> introducing and using an `iss` authorization response parameter has always 
>> seemed like the most straightforward approach for mitigating the issue 
>> (which was part of the draft-ietf-oauth-mix-up-mitigation but other 
>> parameters were also included and, for reasons I'm not sure about, interest 
>> in that work faded in favor of telling clients to use per AS redirect URIs) 
>> . Though for the `iss` authorization response parameter to be effective, all 
>> parties involved need to know about it and act on it. So I think it'd need 
>> to be something more than a passing recommendation in the BCP. It should be 
>> defined, registered, explained, etc.. Actually introducing a new parameter 
>> is maybe going beyond the expected scope of the BCP (or 2.1). But maybe 
>> that's ok, if we're at least more intentional about it. 
>>  
>> On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett  wrote:
>> Hi all,
>> I was wondering if we should move towards introducing and (more explicitly) 
>> recommending the iss parameter in the security BCP, for the reasons laid out 
>> below and in the article (which is now 
>> athttps://danielfett.de/2020/05/04/mix-up-revisited/).
>>  
>> Any thoughts on this?
>>  
>> -Daniel
>>  
>> Am 04.05.20 um 19:34 schrieb Daniel Fett:
>> Hi all,
>> 
>> to make substantiated recommendations for FAPI 2.0, the security 
>> considerations for PAR, and the security BCP, I did another analysis on the 
>> threats that arise from mix-up attacks. I was interested in particular in 
>> two questions:
>> 
>>  • Does PAR help preventing mix-up attacks?
>>  • Do we need JARM to prevent mix-up attacks?
>> I wrote down several attack variants and configurations in the following 
>> document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html
>> 
>> The key takeaways are:
>> 
>>  • The security BCP needs to make clear that per-AS redirect URIs are 
>> only sufficient if OAuth Metadata is not used to resolve multiple issuers. 
>> 

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

[Torsten Lodderstedt]

> On 11. Aug 2020, at 23:55, Brian Campbell 
>  wrote:
> 
> Hi Francis, 
> 
> My apologies for the tardy response to this - I was away for some time on 
> holiday. But thank you for the review and feedback on the draft. I've tried 
> to respond inline below.
> 
> 
> On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha 
>  wrote:
> Bellow is the only remark I found from reviewing the draft draft:
> 
> 2.1.  Request: 
> 
> requires the parameters "code_challenge" and "code_challenge_method" but
> https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential-client
>  mentions that RFC7636 is not required for confidential clients. I guess 
> those two parameters have to be taken off the mandatory list and pushed to 
> the list below.
> 
> The list of parameters in Section 2.1 is qualified with a "basic parameter 
> set will typically include" and is definitely not intended to convey a set of 
> required parameters. It's just a list of parameters that make up a 
> hypothetical typical request.  Perhaps some text in the section or even the 
> formatting needs to be adjusted so as to (hopefully) avoid any confusion like 
> this that the list somehow conveys normative requirements?

Just a note: according to 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics and 
https://tools.ietf.org/html/draft-ietf-oauth-v2-1, code_challenge is a 
mandatory parameter for any client. That’s why we included it in this list. 

The FAPI WG also considers to make PKCE mandatory in FAPI 1. FAPI 2 requires it 
anyway. 

> 
>  
> - Using jwsreq, non repudiation is provided as request is signed (jws). This 
> section also mentions that the request can be sent as form url  encoded 
> (x-www-form-urlencoded). In this case, there is no way to provide non 
> repudiation unless we mention that request can be signed by client using 
> signature methods declared by the AS (AS metadata).
> 
>  I am not aware of any signature methods or means of an AS declaring support 
> for a signature method in metadata that are sufficiently standardized to be 
> mentioned in the context of this draft. The "request" parameter 
> https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 can be sent to 
> the PAR endpoint and should provide the same notation of non-repudiation as 
> does jwsreq. I think that's sufficient treatment of non-repudiation for the 
> PAR draft. 
> 
>  
> 
> 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] WGLC Review of PAR

[Torsten Lodderstedt]

> 
> 
> ¶6: Does the AS really have "the ability to authenticate and authorize 
> clients”? I think what we mean here is "the ability to authenticate clients 
> and validate client requests”, but I’m not positive of the intent. 
> 
> I think the intent is that the AS can check whether a client is authorized to 
> make a particular authorization request (specific scopes, response type, 
> etc.). But checking authorization to request authorization is confusing 
> wording. I think your working is less confusing and still allows for the 
> intent. 
> 
> I'll let Torsten interject if he feels differently as I think he originally 
> wrote the text in question. 

that was the original intent. I think “validate" is fine. 

> 
>  
> 
> ¶7: I’m not sure I buy this example. Even if the clientID is managed 
> externally, the association with a set or pattern of allowed redirect URIs is 
> still important, and the AS will need to know what that is. I think this 
> example could lead an AS developer to (erroneously and dangerously) conclude 
> that they don’t have to check any other values in a request, including scope 
> and redirect URI. It’s important that DynReg doesn’t alleviate that issue, 
> but removal of DynReg doesn’t really change things in that regard. Suggest 
> removing example or reworking paragraph.
> 
> I'm going to have to defer to Torsten on this because, to be honest, I'm not 
> too sure about it myself. I tend to lean towards thinking the draft would be 
> better off without it. 
> 

In the traditional authorization flow, the redirect_uri serves as way to make 
sure the AS is really talking to the legit client and the allowed redirect_uri 
values are determined by the legit client at registration time (might be 
manually).

With PAR, we have a much stronger means to ensure the AS is talking to the 
legit client. That’s why I don’t see an issue with letting the client set a per 
transaction redirect_uri. This will give the client more flexibility (mint 
AS-specific redirect URIs on the fly) and makes client management much easier 
since redirect URIs are the most volatile part of a client policy. 

It also makes use of OAuth much easier in deployments where client identities 
are managed by external entities (even without any idea of OAuth). A prominent 
example is open banking in the EU (aka PSD2). The (technical) identity of any 
PSD2-licensed client is asserted by an eIDAS compliant CA in a special X.509 
certificate. Those certificates contain the permissions (access to account 
information and/or payment initiation allowed) and the identity (member state 
specific). But they don’t contain OAuth policy values. Nevertheless, the 
regulation requires any financial institution in the EU to at runtime, without 
any registration, to accept and process calls from any licensed PSD2 clients.

There are two ways to cope with it in OAuth context:
a) use dynamic client registration with the X.509 cert as credential. 
Unfortunately, RFC 7591 does not support other client authentication means then 
an initial access token. Beside that, it would violate the text of the 
regulation. 
b) establish a redirect URL with every transaction. This is the recommended 
approach in at least one of the PSD2 specs.

PAR is a clean way to solve that problem. 

I don’t want this text to cause confusing. On the other hand this potential of 
PAR is way too important to not mention it at all. What about moving it into a 
special section "redirect_uri management”?

> 

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

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

You are making a good point here. The reason we added the one time use 
constraint was the fact the client will include parameters supposed to be used 
only once, e.g. the PKCE code_challenge. For a traditional authorisation 
request, we would recommend the client to use a per transaction (== one time 
use) code_challenge, but PKCE does not require the AS to enforce it. Mapping 
this to PAR means, we SHOULD recommend the client to use the request_uri only 
once but not require the AS to enforce it. 

Would the following text work for you?

Since parts of the request content, e.g. the "code_challenge"
   parameter value, is unique to a certain authorization request, 
the client SHOULD use the "request_uri" only once.

I also would move this text to section 4.

> On 27. Aug 2020, at 18:11, Dick Hardt  wrote:
> 
> That is not correct.
> 
> The authorization code one-time-use is directly between the client and the 
> AS. The client has a number of mechanisms to ensure it only presents the 
> authorization code to the AS once, such as a session that was set when the 
> user started at the client.
> 
> In contrast, in a redirect from the client to the AS, the client loses 
> control on how many times the user-agent loads the URL at the AS. 
> Additionally, there is unlikely to be an active browser session at the AS, so 
> the AS can not easily differentiate between a URL load from the same user, or 
> different users. If one-time-use, one of them MUST fail. If the two requests 
> happen to be from the same user (because of a reload, which the user did 
> because the AS was slow to respond), there is no way for the AS to know which 
> of the requests is the one that is current in front of the user. While the AS 
> can internally ensure processing of the request once, one-time-use would 
> dictate that it provides a failure message to one of the requests.
> 
> /Dick
> 
> 
> ᐧ
> 
> On Thu, Aug 27, 2020 at 7:17 AM Justin Richer  wrote:
> We already have this same property with authorization codes, and it’s managed 
> today reasonably well (in my opinion). If you submit the same request URI 
> twice in the same browser (the refresh you’re talking about), it shouldn’t 
> start two separate authorization requests, but it would be reasonable to 
> detect that the same session attached to the same request URI value showed up 
> twice and continue the session as appropriate. 
> 
> None of this is in conflict with “one time use”, in my view, since you’re 
> actively detecting the session and source of the value.
> 
>  — Justin
> 
>> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
>> 
>> I think one-time use may be overly restrictive, and I don't think it is the 
>> property that we actually want.
>> 
>> Give the request URI is in a redirect from the browser, there is a good 
>> chance of a race condition where the same browser request is made more than 
>> once, for example, while the browser is loading the authorization URL at the 
>> AS, the user could refresh the page causing the authorization URL to be 
>> reloaded. Would the reload count as a second use? One could argue it either 
>> way.
>> 
>> What I think we want from what I understand, is the request URI MUST be 
>> unique so that there is no confusion on which request is being referenced. 
>> 
>> I did not see anything about the expiry time of the request URI (but I did 
>> not look super hard). If that is not there, then I think the request URI 
>> MUST expire in a "short" period of time.
>> 
>> 
>> 
>> ᐧ
>> 
>> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
>>  wrote:
>> Thanks Justin. Just a couple more responses to responses inline below (but 
>> with lots of content that needs no further discussion removed). 
>> 
>> A TL;DR for the WG is that I'd like to get some wider feedback on the 
>> question of changing the one-time-use condition on the request_uri from a 
>> SHOULD to a MUST. 
>> 
>> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
>> Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
>> going through everything!
>>  — Justin
>> 
>>> On Aug 25, 2020, at 6:01 PM, Brian Campbell  
>>> wrote:
>>> 
>>> Thanks for the review and comments Justin. Replies (or attempts thereat) 
>>> are inline below.
>>> 
>>> 
>>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
>>> I’ve done a full read through of the PAR specification, and here are my 
>>> notes on it.
>>> 
>>> 
>>> ¶2: Of necessity, this spec mixes parameters in the authorization 
>>> endpoint and token endpoint registries into a single request. Is there any 
>>> danger of conflict between them? The registry holds them in one list but 
>>> they could possibly have different semantics in both places..
>>> 
>>> I think that technically such danger does exist but that it's highly 
>>> unlikely in practice. Especially because the only token endpoint parameters 
>>> that are relevant to PAR are those that deal with client authentication 
>>> (currently client_secret, 

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

> On 28. Aug 2020, at 16:56, Dick Hardt  wrote:
> 
> Well, OAuth is not very useful in a monolithic application. No need for an 
> interoperable protocol for that kind of application.

I don’t know why we need to make any assumptions about the application that 
uses OAuth. A lot of assumptions might turn out to be wrong. So if me make 
assumptions they must be relevant for the protocol design. 

So again, why is “independent” or “third-party” relevant for the protocol 
design? 

> 
> And in separating functions, you are creating separate trust domains. Yes, it 
> is still all internal, but it enables a separation of concerns.
> ᐧ
> 
> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt  
> wrote:
> In my experience OAuth is used in 1st party scenarios as means to separate 
> functions (e.g. central user management vs. different products) within the 
> same trust domain thus enabling architectural flexibility. 
> 
> I would just remove any constraint on the kind of applications OAuth can be 
> used for. I don’t see how this governs the protocol design.  
> 
> > On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> > 
> > The driver in my opinion for first-party use of OAuth is to separate the 
> > trust domains so that the application is scoped in what it can do vs an 
> > application that has full access to all resources. I agree that third-party 
> > can indicate that internal use does not apply. How about the following?
> > 
> >The OAuth 2.1 authorization framework enables an independent
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in RFC 6749.
> > ᐧ
> > 
> > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
> >  wrote:
> > I agree. OAuth works for 3rd as well as 1st parties as well. 
> > 
> > > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> > > 
> > > Hi,
> > > 
> > > Can "third-party" term be removed from the specification?
> > > 
> > > The standard and associated best practices apply to other applications 
> > > that act on behalf of a resource owner, too (internal, "first-party" and 
> > > etc).
> > > 
> > > Regards,
> > > 
> > > Dima
> > > 
> > > The OAuth 2.1 authorization framework enables a third-party
> > > 
> > >application to obtain limited access to an HTTP service, either on
> > >behalf of a resource owner by orchestrating an approval interaction
> > >between the resource owner and the HTTP service, or by allowing the
> > >third-party application to obtain access on its own behalf.  This
> > >specification replaces and obsoletes the OAuth 2.0 Authorization
> > >Framework described in 
> > > RFC 6749.
> > > ___
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 

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

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

In my experience OAuth is used in 1st party scenarios as means to separate 
functions (e.g. central user management vs. different products) within the same 
trust domain thus enabling architectural flexibility. 

I would just remove any constraint on the kind of applications OAuth can be 
used for. I don’t see how this governs the protocol design.  

> On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> 
> The driver in my opinion for first-party use of OAuth is to separate the 
> trust domains so that the application is scoped in what it can do vs an 
> application that has full access to all resources. I agree that third-party 
> can indicate that internal use does not apply. How about the following?
> 
>The OAuth 2.1 authorization framework enables an independent
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in RFC 6749.
> ᐧ
> 
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
>  wrote:
> I agree. OAuth works for 3rd as well as 1st parties as well. 
> 
> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> > 
> > Hi,
> > 
> > Can "third-party" term be removed from the specification?
> > 
> > The standard and associated best practices apply to other applications that 
> > act on behalf of a resource owner, too (internal, "first-party" and etc).
> > 
> > Regards,
> > 
> > Dima
> > 
> > The OAuth 2.1 authorization framework enables a third-party
> > 
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >third-party application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in 
> > RFC 6749.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

I agree. OAuth works for 3rd as well as 1st parties as well. 

> On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> 
> Hi,
> 
> Can "third-party" term be removed from the specification?
> 
> The standard and associated best practices apply to other applications that 
> act on behalf of a resource owner, too (internal, "first-party" and etc).
> 
> Regards,
> 
> Dima
> 
> The OAuth 2.1 authorization framework enables a third-party
> 
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>third-party application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in 
> RFC 6749.
> ___
> 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] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

Will the following text work for you?

Implementers should be aware that a token introspection request lets the AS 
know when the client 
 (and potentially the user) is accessing the RS, which is also an 
indication of when the user is using 
 the client. If this impliction is not accepatable, implementars MUST use 
other means to carry 
 access token data, e.g. directly transferring the data needed by the RS 
within the access token.


> On 26. Aug 2020, at 23:12, Mike Jones 
>  wrote:
> 
> I agree with Dick’s observation about the privacy implications of using an 
> Introspection Endpoint.  That’s why it’s preferable to not use one at all and 
> instead directly have the Resource understand the Access Token.  One way of 
> doing this is the JWT Access Token spec.  There are plenty of others.
>  
> The downsides of using an Introspection Endpoint should be described in the 
> Privacy Considerations section.
>  
>-- Mike
>  
> From: OAuth  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call: 
>  (JWT Response for OAuth 
> Token Introspection) to Proposed Standard
>  
>  
>  
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>  wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis  wrote:
> 
> > The fact that the AS will know exactly when the introspection call has been 
> > made and thus be able to make sure which client 
> > has attempted perform an access to that RS and at which instant of time. 
> > The use of this call allows an AS to track where and when 
> > its clients have indeed presented an issued access token.
> 
> That is a fact. I don’t think it is an issue per se. Please explain the 
> privacy implications.
>  
> As I see it, the privacy implication is that the AS knows when the client 
> (and potentially the user) is accessing the RS, which is also an indication 
> of when the user is using the client.
>  
> I think including this implication would be important to have in a Privacy 
> Considerations section.
>  
> /Dick
> ᐧ

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

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09

[Torsten Lodderstedt]

Hi Roman, 

thanks for your review feedback. 

> On 21. Aug 2020, at 16:43, Roman Danyliw  wrote:
> 
> Hi!
> 
> I conducted an another AD review of 
> draft-ietf-oauth-jwt-introspection-response-09.  As background, -07 of this 
> document went to IESG Review and the document was brought back to the WG to 
> address the DISCUSS points.  
> 
> Below is my feedback which can be addressed concurrently with IETF LC.
> 
> ** Section 5.  I want to clarify what are the permissible members of 
> token_introspection.  The two relevant text snippets seem to be:
> 
> (a) "token_introspection  A JSON object containing the members of the
>   token introspection response, as specified in the "OAuth
>   Token Introspection Response" registry established by
>   [RFC7662] as well as other members."
> 
> (b) "Claims from the "JSON Web Token Claims" registry that are
>   commonly used in [OpenID.Core] and can be applied to the
>   resource owner MAY be included as members in the
>   "token_introspection" claim."
> 
> -- Per (a), Recommend citing the IANA sub-registry directly -- 
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response
>  (and not the "as specified in the "OAuth Token Introspection Response" 
> registry established by [RFC7662]")

done 

> 
> -- Per (a), "... as well as other members", what members is this referencing? 
>  Is that (b)?  Recommend being clear upfront on which exact registries are 
> the sources of valid members.

I reworked the whole paragraph (hrefs for registries not shown). 

As specified in section 2.2. of [RFC7662], specific implementations MAY extend 
the token introspection response with service-specific claims. In the context 
of this specification, such claims will be added as top-level members of the 
token_introspection claim. Response names intended to be used across domains 
MUST be registered in the OAuth Token Introspection Response registry defined 
by [RFC7662]. In addition, claims from the JSON Web Token Claims registry 
established by [RFC7519] MAY be included as members in the token_introspection 
claim. They can serve to convey the privileges delegated to the client, to 
identify the resource owner or to provide a required contact detail, such as an 
e-Mail address or phone number. When transmitting such claims the AS acts as an 
identity provider in regard to the RS. The AS determines based on its 
RS-specific policy what claims about the resource owner to return in the token 
introspection response.

Does this work for you?

> 
> -- Per (b), "... commonly used in [OpenId.Core]", what are those 
> specifically?  Is that claims registered in 
> https://www.iana.org/assignments/jwt/jwt.xhtml#claims whose reference is 
> [OpenID Connect Core 1.0]?  Recommend being unambiguous in which claims are 
> permitted by pointing the IANA registry.
> 
> -- If I'm understanding right that the source comes either from 
> oauth-parameters.xhtml#token-introspection-response or jwt.xhtml#claims, what 
> happens if it isn't one of those?

Every implementation is also free to use their own specific claims. This is 
defined in section 2.2. of RFC 

> 
> ** Section 5.  Per " The AS MUST ensure the release of any privacy-sensitive 
> data is legally based", recommend also including a forward reference to 
> Section 9

done

best regards,
Torsten. 

> 
> Regards,
> Roman
> 
> ___
> 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] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

> On 25. Aug 2020, at 18:26, Denis  wrote:
> 
> Here is an additional comment:
> 
> The text mentions in the Introduction: 
> 
>In example is a resource server using verified person data
>to create certificates, which in turn are used to create qualified
>electronic signatures.
> 
> The problem is the following: the AS has no way to verify that the User has 
> effectively authorized the RS 
> to use the JWT Response for such a purpose. A "User Consent" phase for such a 
> usage has not been addressed.  

Why not? The AS can easily ask the resource owner/user in the authorization 
process for consent to transfer certain end user claims to the RS. As a 
pre-requisite, the AS needs to determine what data is transmitted to an RS for 
a certain scope. 

> 
> This concern is identified in RFC 6973 as:
> 
> 5.2.3.  Secondary Use
> 
>Secondary use is the use of collected information about an individual
>without the individual’s consent for a purpose different from that
>for which the information was collected.  Secondary use may violate
>people’s expectations or desires.  The potential for secondary use
>can generate uncertainty as to how one’s information will be used in
>the future, potentially discouraging information exchange in the
>first place.  Secondary use encompasses any use of data, including
>disclosure.
> 
> The progression of this draft is really questionable. The User has currently 
> no way to allow or to disallow this protocol 
> which is between a RS and an AS.  It would not be reasonable to say that this 
> concern is outside the scope of this draft.
> Denis

This is no secondary use, it’s the primary use the user consented with. 


> 
> 
> 
>> This draft contains a "Privacy considerations" section (Section 9).
>> .
>> The content of this section is as follows:
>> 
>>The token introspection response can be used to transfer personal
>>identifiable information from the AS to the RS.  The AS MUST ensure a
>>legal basis exists for the data transfer before any data is released
>>to a particular RS.  The way the legal basis is established might
>>vary among jurisdictions and MUST consider the legal entities
>>involved.
>> 
>>For example, the classical way to establish the legal basis is by
>>explicit user consent gathered from the resource owner by the AS
>>during the authorization flow.
>> 
>>It is also possible that the legal basis is established out of band,
>>e.g. in an explicit contract or by the client gathering the resource
>>owner’s consent.
>> 
>>If the AS and the RS belong to the same legal entity (1st party
>>scenario), there is potentially no need for an explicit user consent
>>but the terms of service and policy of the respective service
>>provider MUST be enforced at all times.
>> 
>>In any case, the AS MUST ensure that the scope of the legal basis is
>>enforced throughout the whole process.  The AS MUST retain the scope
>>of the legal basis with the access token, e.g. in the scope value,
>>and the AS MUST determine the data a resource server is allowed to
>>receive based on the resource server’s identity and suitable token
>>data, e.g. the scope value.
>> 
>> It is not believed that these explanations are useful, nor sufficient.
>> 
>> Talking a "legal basis" without translating legal constraints into technical 
>> constraints is not useful.
>> Since sensitive information may be returned, the text should say that AS 
>> should/must make sure that the requesting RS is indeed 
>> authenticated and allowed to perform this operation.
>> 
>> However, section 4 is only using the verb "SHOULD" whereas it should use the 
>> verb "SHALL" :
>> The AS SHOULD authenticate the caller at the token introspection endpoint.
>> Talking of "an explicit user consent gathered from the resource owner by the 
>> AS" does not make sense.
>> Either the operation is allowed or is not allowed by the RO, but there is no 
>> "RO consent".
>> 
>> About RFC 7662 (OAuth 2.0 Token Introspection)
>> 
>> One might think that the important considerations have already been provided 
>> when issuing RFC 7662 (OAuth 2.0 Token Introspection) 
>> which contains a Privacy considerations section (section 5).
>> 
>> The third sentence states:
>> One method is to transmit user identifiers as opaque service-specific 
>> strings, potentially returning different identifiers to each protected 
>> resource.
>> This would mean that the response would not reflect the content of the 
>> token. Furthermore, the RS would not even be informed of such a 
>> transformation.
>> 
>> The last sentence even states:
>> Omitting privacy-sensitive information from an introspection response is the 
>> simplest way of minimizing privacy issues.
>> In such a case, the introspection query becomes more or less useless.
>> 
>> What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?
>> 
>> The fact that 

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis  wrote:

thanks for the review and your feedback. 

> 
> 
> This draft contains a "Privacy considerations" section (Section 9).
> .
> The content of this section is as follows:
> 
>The token introspection response can be used to transfer personal
>identifiable information from the AS to the RS.  The AS MUST ensure a
>legal basis exists for the data transfer before any data is released
>to a particular RS.  The way the legal basis is established might
>vary among jurisdictions and MUST consider the legal entities
>involved.
> 
>For example, the classical way to establish the legal basis is by
>explicit user consent gathered from the resource owner by the AS
>during the authorization flow.
> 
>It is also possible that the legal basis is established out of band,
>e.g. in an explicit contract or by the client gathering the resource
>owner’s consent.
> 
>If the AS and the RS belong to the same legal entity (1st party
>scenario), there is potentially no need for an explicit user consent
>but the terms of service and policy of the respective service
>provider MUST be enforced at all times.
> 
>In any case, the AS MUST ensure that the scope of the legal basis is
>enforced throughout the whole process.  The AS MUST retain the scope
>of the legal basis with the access token, e.g. in the scope value,
>and the AS MUST determine the data a resource server is allowed to
>receive based on the resource server’s identity and suitable token
>data, e.g. the scope value.
> 
> It is not believed that these explanations are useful, nor sufficient.
> 
> Talking a "legal basis" without translating legal constraints into technical 
> constraints is not useful.
> Since sensitive information may be returned, the text should say that AS 
> should/must make sure that the requesting RS is indeed 
> authenticated and allowed to perform this operation.
> 
> However, section 4 is only using the verb "SHOULD" whereas it should use the 
> verb "SHALL" :
> The AS SHOULD authenticate the caller at the token introspection endpoint.

Good point. I added the requirement to authenticate the RS if privacy sensitive 
data is released to section 9. I’m reluctant to make it a general requirement 
since RFC 7662 also does not require all RSs to authenticate. 

> Talking of "an explicit user consent gathered from the resource owner by the 
> AS" does not make sense.
> Either the operation is allowed or is not allowed by the RO, but there is no 
> "RO consent".

I don’t understand your argument. The OAuth authorization flow is conducted 
with the resource owner and it is the resource owner who gives consent to the 
requested scopes to the AS. What do you mean by there is no "RO consent”?

> 
> About RFC 7662 (OAuth 2.0 Token Introspection)
> 
> One might think that the important considerations have already been provided 
> when issuing RFC 7662 (OAuth 2.0 Token Introspection) 
> which contains a Privacy considerations section (section 5).
> 
> The third sentence states:
> One method is to transmit user identifiers as opaque service-specific 
> strings, potentially returning different identifiers to each protected 
> resource.
> This would mean that the response would not reflect the content of the token. 
> Furthermore, the RS would not even be informed of such a transformation.
> 
> The last sentence even states:
> Omitting privacy-sensitive information from an introspection response is the 
> simplest way of minimizing privacy issues.
> In such a case, the introspection query becomes more or less useless.
> 
> What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?
> 
> The fact that using an introspection call can be avoided and should be 
> avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], 
> the contents of tokens are opaque to clients", it is not opaque to RSs. As 
> soon as the RS knows the format of the access token and is able 
> to validate its security features, this call should be avoided.
> 
> So what should be mentioned in section 9 ?
> 
> The fact that the AS will know exactly when the introspection call has been 
> made and thus be able to make sure which client 
> has attempted perform an access to that RS and at which instant of time. The 
> use of this call allows an AS to track where and when 
> its clients have indeed presented an issued access token.

That is a fact. I don’t think it is an issue per se. Please explain the privacy 
implications. 

Token introspection has several advantages over structured access tokens, also 
when it comes to privacy. If one uses a structured access token in conjunction 
with different services, then this access token needs to contain ALL data 
required to call ALL these services. This effectively means the services learn 
more data than required. One could try to mitigate this by carrying encrypted 
compartments in the same token, each of 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-02.txt

[Torsten Lodderstedt]

Hi all, 

the new RAR revision clarifies the “type” parameter processing. 

best regards,
Torsten. 

> On 21. Aug 2020, at 16:16, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
> 
>Title   : OAuth 2.0 Rich Authorization Requests
>    Authors     : Torsten Lodderstedt
>  Justin Richer
>  Brian Campbell
>   Filename: draft-ietf-oauth-rar-02.txt
>   Pages   : 31
>   Date: 2020-08-21
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-rar-02
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-02
> 
> 
> 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

Re: [OAUTH-WG] Client authentication on token revocation

[Torsten Lodderstedt]

Hi Emond, 

I tend to agree with your assessment. Revoking bearer tokens without client 
authentication seems to be better than leaving the attacker the option to use 
them to invoke resources. 

However, if the attacker cannot use the access tokens (e.g. because they are 
sender constrained), the attacker could revoke tokens issued to a confidential 
client as a kind of DoS attack. 

best regards,
Torsten. 

> On 20. Aug 2020, at 11:02, Emond Papegaaij  wrote:
> 
> Hi all,
> 
> We are currently implementing the token revocation endpoint (RFC 7009)
> on our authorization server and do not understand why it requires
> client authentication. When a party (a valid client or not) gets hold
> of a valid access token in whatever way, the least damaging it could
> do with it, is to revoke it. The current spec allows an attacker to
> misuse this token for access to the resource server, but forbids it to
> revoke it. This seems strange to me.
> 
> Section 5 of RFC 7009 does not help in this either. It starts to
> explain that this authentication is needed to prevent malicious
> clients from guessing tokens, but ends with the fact that if this were
> possible, much worse damage could be done by using the guessed token
> on the resource server. We plan to skip the authentication all
> together and simply revoke any valid token presented. How would you
> recommend we deal with this?
> 
> Best regards,
> Emond Papegaaij
> Topicus KeyHub
> 
> ___
> 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] Namespacing "type" in RAR

[Torsten Lodderstedt]

Hi,

the wording regarding type works for me.

Similar to Brian, I don’t understand how the data type registry is supposed to 
work.

In my opinion, type and locations are completely different from the other 
elements since they are required by the protocol itself. Their semantics must 
not be changed by applications.

The other element types are reusable components, but I don’t understand how an 
application or standard would refer to them, include them into there type 
definition, and how overloading might happen. For example, are these elements 
always included in the top level container or can they be used deeper in the 
structure?

There are alternative solutions for reuse. I personally would use JSON schemas 
to define such reusable elements and the authorization data types utilizing 
them. 

I therefore don’t see the need for a RAR specific mechanism (a registry).

best regards,
Torsten.

> Am 26.07.2020 um 02:48 schrieb Justin Richer :
> 
> Brian,
> 
> I can appreciate the confusion on the elements registry. It’s really about 
> having a place to put re-usable components that people might use within their 
> own “type” definitions, if they want to. The construct in use there is 
> similar to what we used in Vectors of Trust (RFC8485), 
> https://tools.ietf.org/html/rfc8485
> 
> A VoT “trust framework” document can technically define whatever categories 
> and values that it wants to. However, there is a registry for common 
> categories, designed to be core dimensions applicable across a number of 
> different trust frameworks. 
> 
> So the way that it works is that a “type” can redefine its own syntax and 
> semantics for something like “actions” or “locations”, if it wants to, but 
> the registry is giving people a place to look and say, “oh hey, someone 
> already uses ‘actions’ in a general way, maybe that works for me and I can 
> use that definition, or maybe I should find a different word”. So while 
> “type” avoids the programmatic namespace collision of two different 
> definitions of “action”, the registry helps to avoid developer confusion 
> about having two different uses for the same word. 
> 
> It’s not foolproof, but it’s better than making every API designer start from 
> a completely blank slate.
> 
>  — Justin
> 
>> On Jul 24, 2020, at 5:55 PM, Brian Campbell  
>> wrote:
>> 
>> I think I'm on board with the type being a just string and the guidance 
>> provided about collision-resistance (rather than having a registry for types 
>> or requiring type to be a URI or something along those lines). I don't 
>> believe there's actually an issue with string comparison in that context and 
>> so see no need for the draft to say anything special about it. 
>> 
>> In looking at the pull request, however, I'm surprised by there being a 
>> registry for the data elements. And honestly confused about how that would 
>> even work in practice. The contents of the authorization details object are 
>> determined by the `type` parameter but there's also a registry of the 
>> elements that can make up that content that are general across type. I don't 
>> see how to reconcile that. 
>> 
>> On Mon, Jul 20, 2020 at 10:00 AM Justin Richer  wrote:
>>> I created a pull request with some proposed language here:
>>> 
>>> https://github.com/oauthstuff/draft-oauth-rar/pull/52
>>> 
>>>  — Justin
>>> 
 On Jul 20, 2020, at 7:42 AM, Justin Richer  wrote:
 
 Since this is a recommendation for namespace, we could also just say 
 collision-resistant like JWT, and any of those examples are fine. But that 
 said, I think there’s something particularly compelling about URIs since 
 they have somewhat-human-readable portions. But again, I’m saying it 
 should be a recommendation to API developers and not a requirement in the 
 spec. In the spec, I argue that “type” should be a string, full stop.
 
 If documentation is so confusing that developers are typing in the wrong 
 strings, then that’s bad documentation. And likely a bad choice for the 
 “type” string on the part of the AS. You’d have the same problem with any 
 other value the developer’s supposed to copy over.  :)
 
 I agree that we should call out explicitly how they should be compared, 
 and I propose we use one of the handful of existing string-comparison 
 RFC’s here instead of defining our own rules.
 
 While the type could be a dereferenceable URI, requiring action on the AS 
 is really getting into distributed authorization policies. We tried doing 
 that with UMA1’s scope structures and it didn’t work very well in practice 
 (in my memory and experience). Someone could profile “type" on top of this 
 if they wanted to do so, with support at the AS for that, but I don’t see 
 a compelling reason for that to be a requirement as that’s a lot of 
 complexity and a lot more error states (the fetch fails, or it doesn’t 
 have a policy, or the policy’s 

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Torsten Lodderstedt]

Hi Aaron, 

that’s a very good point. I was also in favour of just providing the client 
with the URL it needs to send the user to (like XYZ and OAuth do). 

In the end, we decided to stay with the current approach since it fits with the 
rest of the existing ecosystem, namely JAR and authorization endpoint 
discovery. 

best regards,
Torsten. 

> On 24. Jul 2020, at 00:49, Aaron Parecki  wrote:
> 
> I know this is a bit of an old thread to dig up, but as I'm working through 
> this draft again, something is sticking out to me about this.
> 
> In every other instance of "*_uri" in OAuth and extensions, the value is a 
> URI (usually https) which will be visited by the user's browser or be sent a 
> POST request from a client. In the case of PAR, this "request_uri" is 
> actually just an identifier that is *added* to an existing URL, the 
> authorization endpoint, not a URL that will be visited itself. This 
> discrepancy is bothering me.
> 
> I would have expected that either:
> 
> * The PAR response includes a "request_uri" which is the full URL that the 
> client would redirect the user's browser to, OR
> * The PAR response includes a "request_id" which it adds in the query string 
> to the authorization endpoint and then redirects the browser to
> 
> For example:
> 
> POST /as/par HTTP/1.1
> ...
> response:
> {
>   "request_uri": 
> "https://as.example.com/auth?request=bwc4JK-ESC0w8acc191e-Y1LTC2;,
>   "expires_in": 60
> }
> 
> then the user's browser is sent to whatever the value of "request_uri" is
> 
> OR
> 
> POST /as/par HTTP/1..1
> ...
> response:
> {
>   "request_id": 
> "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
>   "expires_in": 60
> }
> 
> then the "request_id" is added to the authorization endpoint (as currently 
> described by PAR)
> 
> https://as.example.com/auth?client_id=s6BhdRkqt3_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2
> 
> My personal preference is the first option, keeping the term "request_uri" 
> but having it actually be the full URI, to simplify the job of the client. In 
> that model, the client doesn't have to mess with building URLs, and actually 
> provides additional flexibility for the AS as well since that endpoint no 
> longer needs to be the exact same URL as the authorization endpoint.. 
> 
> ---
> Aaron Parecki
> https://aaronparecki.com
> 
> 
> On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt 
>  wrote:
> I just thought about another option. What if we change PAR to not use the 
> request_uri parameter but a new parameter, e.g. request_id?
> 
> That would decouple both specs. The reason why we use request_uri was to make 
> the life of clients easier since they can use the standard library function 
> for request objects to pass the PAR reference to the AS. Is this worth the 
> trouble?
> 
>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>> 
>> +1 to this approach, and it sounds like JAR might need to come back to go 
>> through another round anyway thanks to the breaking changes the IESG pushed 
>> into it after it left WGLC.
>> 
>> I’d rather see us get this right than publish something many of us think is 
>> broken. 
>> 
>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>> 
>>  — Justin
>> 
>>> 
> 
> ___
> 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] Namespacing "type" in RAR

[Torsten Lodderstedt]

> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov  wrote:
> 
> 
> On 21/07/2020 18:43, Torsten Lodderstedt wrote:
>> 
>>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov  
>>> wrote:
>>> 
>>> 
>>> 
>>> On 21/07/2020 17:47, Justin Richer wrote:
>>>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov  
>>>>> wrote:
>>>>> 
>>>>> On 18/07/2020 17:12, Justin Richer wrote:
>>>>>> I think publishing supported “type” parameters isn’t a bad idea, and it 
>>>>>> aligns with publishing supported scopes and claims in discovery.
>>>>> If you are a developer, would you like to be able to find out if the 
>>>>> authorization_details for a given "type" has a JSON schema and what it 
>>>>> looks like?
>>>>> 
>>>>> 
>>>>> 
>>>> I think that would be a nice thing for an AS/API to offer, but I don’t 
>>>> think it should be expected or required here. That might be a good note in 
>>>> the guidance, say that if you use a URI for your “type” field then it 
>>>> would be nice if it resolved to something either human or machine 
>>>> readable. What I don’t want is for us to require every AS to have to 
>>>> resolve these URIs in order to process and understand them. That’s why I’m 
>>>> taking the position of it being a string, and the URI can provide 
>>>> disambiguation in the way you’re talking about below.
>>> We've been thinking about giving developers the possibility to discover the 
>>> authorization_details JSON schema (if one is supplied) for a given type via 
>>> a separate AS metadata parameter. Not by making the type a dereferceable 
>>> URL, which will overload things too much.
>>> 
>>> authorization_details_json_schemas : {
>>>"" : "",
>>>"" : "",
>>>   ...
>>> 
>>> }
>>> The rationale -- to minimise the number of potential support calls for 
>>> providers arising from "Oh dear, why do I get this invalid_request now..." 
>>> with complex RAR JSON objects.
>> We could borrow the "$schema” element. 
> 
> Could you elaborate?

I mean we could use this element in addition to the “type” element to specify 
the corresponding schema in each authorization details object.  

> 
>> However, I’m on the fence regarding introducing a separate parameter for the 
>> schema simply because it also introduce a new error cause if type and schema 
>> are inconsistent. 
> 
> Another idea was to still let the AS be configured with optional JSON
> schemas for each type, and if the schema check of the
> authorization_details fails, to include a meaningful message in the
> invalid_request error_description and the schema URL in the error_uri.
> 
> The downside of that is the schema cannot be discovered or retrieved
> upfront.
> 
> We really want to make it easy for developers to debug their requests
> when facing complex RARs, on their own, without having to rely on a
> support desk.
> 
> IMO the std invalid_request is ok for communicating the condition of an
> authorization_details object failing the schema check (if the additional
> error code was your concern).
> 
> Vladimir
> 
> 
> ___
> 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] Namespacing "type" in RAR

[Torsten Lodderstedt]

> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov  wrote:
> 
> 
> 
> On 21/07/2020 17:47, Justin Richer wrote:
>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov  
>>> wrote:
>>> 
>>> On 18/07/2020 17:12, Justin Richer wrote:
 I think publishing supported “type” parameters isn’t a bad idea, and it 
 aligns with publishing supported scopes and claims in discovery.
>>> If you are a developer, would you like to be able to find out if the 
>>> authorization_details for a given "type" has a JSON schema and what it 
>>> looks like?
>>> 
>>> 
>>> 
>> I think that would be a nice thing for an AS/API to offer, but I don’t think 
>> it should be expected or required here. That might be a good note in the 
>> guidance, say that if you use a URI for your “type” field then it would be 
>> nice if it resolved to something either human or machine readable. What I 
>> don’t want is for us to require every AS to have to resolve these URIs in 
>> order to process and understand them. That’s why I’m taking the position of 
>> it being a string, and the URI can provide disambiguation in the way you’re 
>> talking about below.
> We've been thinking about giving developers the possibility to discover the 
> authorization_details JSON schema (if one is supplied) for a given type via a 
> separate AS metadata parameter. Not by making the type a dereferceable URL, 
> which will overload things too much.
> 
> authorization_details_json_schemas : {
> "" : "",
> "" : "",
>...
> 
> }
> The rationale -- to minimise the number of potential support calls for 
> providers arising from "Oh dear, why do I get this invalid_request now..." 
> with complex RAR JSON objects.

We could borrow the "$schema” element. 

However, I’m on the fence regarding introducing a separate parameter for the 
schema simply because it also introduce a new error cause if type and schema 
are inconsistent. 

best regards,
Torsten. 

> 
> 
> 
> Vladimir
> 
> 
> 
> ___
> 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.1 document

[Torsten Lodderstedt]

+1

> On 15. Jul 2020, at 21:37, John Bradley  wrote:
> 
> I support addoption
> 
> On 7/15/2020 3:32 PM, Neil Madden wrote:
>> I support adoption. 
>> 
>>> On 15 Jul 2020, at 18:42, Rifaat Shekh-Yusef  
>>> wrote:
>>> 
>>> 
>>> All,
>>> 
>>> This is a call for adoption for the following OAuth 2.1 document as a WG 
>>> document:
>>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>>> 
>>> Please, provide your feedback on the mailing list by July 29th.
>>> 
>>> Regards,
>>>  Rifaat & Hannes
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> On 9. Jul 2020, at 19:58, Neil Madden  wrote:
> 
> The point is that RAR can’t make payment transactions the primary use-case, 
> emphasised throughout the draft, and then fail to even discuss this issue or 
> make any kind of suggestion as how to handle it. 

I’m still trying to understand the issue and your proposed solution. What you 
are suggesting is an OAuth authorization to subsequently send another more 
detailed or transactional OAuth authorization. 

If your basic assumption is that users just accept a payment conformation 
screen, why do you think the additional pre-authorization won’t be accepted 
straight away?

The way PSD2 uses to secure such transactions is transaction authorization 
using a dynamic second factor (called strong customer authentication). I assume 
the rational is SCA will make users think before they confirm. 



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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> On 9. Jul 2020, at 19:28, Neil Madden  wrote:
> 
> On 9 Jul 2020, at 18:10, Torsten Lodderstedt  wrote:
>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> What in particular should the use consent with in this step?
>>>>>>>>> 
>>>>>>>>> “FooPay would like to:
>>>>>>>>> - initiate payments from your account (you will be asked to approve 
>>>>>>>>> each one)”
>>>>>>>>> 
>>>>>>>>> The point is that a client that I don’t have any kind of relationship 
>>>>>>>>> with can’t just send me a request to transfer $500 to some account. 
>>>>>>>> 
>>>>>>>> Are we talking about legal consent or a security measures here?
>>>>>>> 
>>>>>>> Normal OAuth consent. My phone is my resource, and I am its resource 
>>>>>>> owner. If a client wants to send payment requests to my phone (e.g. via 
>>>>>>> CIBA backchannel) then it should have to get my permission first. Even 
>>>>>>> without backchannel requests, I’d much rather that only the three 
>>>>>>> clients I’ve explicitly consented to can ask me to initiate payments 
>>>>>>> rather than the hundreds/thousands clients my bank happens to have a 
>>>>>>> relationship with.
>>>>>> 
>>>>>> To me it sounds like you would like to require a client to get user 
>>>>>> authorization to send an authorization request. Would you require the 
>>>>>> same if I would use scope values to encode a payment initiation request?
>>>>> 
>>>>> Yes. If something is sufficiently high value to require per-transaction 
>>>>> authorization then initiating transactions itself becomes a privileged 
>>>>> operation. 
>>>> 
>>>> The per transaction authorization alone is a significant increase in 
>>>> security. What is the added value of requiring an authorization to send a 
>>>> per-transaction authorisation request in an additional step?
>>> 
>>> Because Open Banking allows any client at any time to send an asynchronous 
>>> back channel request to my phone to approve a payment. This is pretty 
>>> risky. 
>> 
>> Can you please explain how you came to that conclusion and how it relates to 
>> RAR?
> 
> https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html
> 
> Client (PISP) initiates a payment-order consent using a client_credentials 
> access token, then launches a CIBA backchannel authorization request. What 
> prevents this?

The fact that the PISP cannot issue this request without a valid user 
identifier. The demos I’m remembering use a traditional first authorization 
flow to establish this identifier.

> 
> This relates to RAR, because RAR also has no protection against this. If you 
> use RAR in combination with a backchannel authorization method then the same 
> issue applies. This is a general issue with backchannel approaches,

Exactly! It's a problem with any kind of backchannel initiated _user 
interaction_. 


> but it is particularly a risk here because RAR is pitching itself as a way to 
> do payment transactions.

The problem is the backchannel request, not RAR. RAR is just a more elaborated 
scope.

> 
>> 
>> In the simplest of all scenarios the client sends authorization details 
>> instead of scope values through the user browser and this way starts the 
>> authorization process with the AS.
>> 
>> When RAR is combined with PAR, the client first stores the authorization 
>> request including authorization details at the AS in exchange for a 
>> reference to this data. It then uses this reference to start the 
>> authorization process. This is more secure and robust than sending the data 
>> through the browser. 
>> 
>> So what is the risk here and why do you think unsolicited backchannel 
>> requests are sent to your device? 
>> 
>> 
>>> 
>>> I can’t think of another transactional auth system that allows this without 
>>> some kind of initial indication of user consent. For example, in Apple Pay 
>>> all payment requests must be initiated from an explicit user gesture, 
>>> providing some indication that the user wants to use this. The Dropbox 
>>> Chooser and Saver APIs also have to be triggered from a user gesture. 
>>

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

 
 What in particular should the use consent with in this step?
>>> 
>>> “FooPay would like to:
>>> - initiate payments from your account (you will be asked to approve 
>>> each one)”
>>> 
>>> The point is that a client that I don’t have any kind of relationship 
>>> with can’t just send me a request to transfer $500 to some account. 
>> 
>> Are we talking about legal consent or a security measures here?
> 
> Normal OAuth consent. My phone is my resource, and I am its resource 
> owner. If a client wants to send payment requests to my phone (e.g. via 
> CIBA backchannel) then it should have to get my permission first. Even 
> without backchannel requests, I’d much rather that only the three clients 
> I’ve explicitly consented to can ask me to initiate payments rather than 
> the hundreds/thousands clients my bank happens to have a relationship 
> with.
 
 To me it sounds like you would like to require a client to get user 
 authorization to send an authorization request. Would you require the same 
 if I would use scope values to encode a payment initiation request?
>>> 
>>> Yes. If something is sufficiently high value to require per-transaction 
>>> authorization then initiating transactions itself becomes a privileged 
>>> operation. 
>> 
>> The per transaction authorization alone is a significant increase in 
>> security. What is the added value of requiring an authorization to send a 
>> per-transaction authorisation request in an additional step?
> 
> Because Open Banking allows any client at any time to send an asynchronous 
> back channel request to my phone to approve a payment. This is pretty risky. 

Can you please explain how you came to that conclusion and how it relates to 
RAR?

In the simplest of all scenarios the client sends authorization details instead 
of scope values through the user browser and this way starts the authorization 
process with the AS.

When RAR is combined with PAR, the client first stores the authorization 
request including authorization details at the AS in exchange for a reference 
to this data. It then uses this reference to start the authorization process. 
This is more secure and robust than sending the data through the browser. 

So what is the risk here and why do you think unsolicited backchannel requests 
are sent to your device? 


> 
> I can’t think of another transactional auth system that allows this without 
> some kind of initial indication of user consent. For example, in Apple Pay 
> all payment requests must be initiated from an explicit user gesture, 
> providing some indication that the user wants to use this. The Dropbox 
> Chooser and Saver APIs also have to be triggered from a user gesture. Again, 
> this provides some confirmation that the user actually initiated the 
> interaction. 
> 
> In OAuth, the AS doesn’t have this level of integration into the client’s UI 
> so it needs some other way to establish user consent. By the time the user 
> has a payment confirmation request on their screen it’s too late. 
> 
> 
>> In case of open banking the user legally consents to this process at the 
>> client (TPP) even before the OAuth/Payment Initiation dance starts. 
> 
> How does the bank (ASPSP) confirm that this actually happened?
 
 It does not because it is not the responsibility of the ASPSP. The TPP is 
 obliged by law to obtain consent.
>>> 
>>> If the TPP can be trusted to obey the law about this, why not also trust 
>>> them to be honest about transactions? Why enforce one thing with access 
>>> tokens but take the other on trust? Especially as the actual transactions 
>>> are more likely to have a rigorous audit trail. 
>>> 
>>> If we could trust clients to obtain consent we wouldn’t need OAuth at all. 
>> 
>> I thought the same initially, but we must distinguish between legal consent 
>> and strong authentication/transaction authorization in such a case. Legal 
>> consent can be obtained in various ways including the traditional OAuth user 
>> consent but also in other places. Authenticating the user (probably with 
>> 2FA) and getting authorization for a certain transaction (the meaning of 
>> PSD2 SCA) must be conducted by the AS. 
>> 
> 
> Do you mean legal protection for the bank or their users? As a user, if an OB 
> client acts in a way that I don’t like, but doesn’t break any actual laws or 
> policies, what’s my recourse? In normal OAuth I can revoke the grant to that 
> client. This is not possible in transactional uses of RAR, and that seems 
> like a big difference that significantly changes the relationship between 
> users and clients. 
> 
> — Neil



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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> On 8. Jul 2020, at 23:52, Neil Madden  wrote:
> 
>> 
>> On 8 Jul 2020, at 20:56, Torsten Lodderstedt  wrote:
>> 
>>> Am 08.07.2020 um 20:46 schrieb Neil Madden :
>>> 
>>> On 8 Jul 2020, at 19:03, Torsten Lodderstedt  
>>> wrote:
>>>>>> 
>>>>>> What in particular should the use consent with in this step?
>>>>> 
>>>>> “FooPay would like to:
>>>>> - initiate payments from your account (you will be asked to approve each 
>>>>> one)”
>>>>> 
>>>>> The point is that a client that I don’t have any kind of relationship 
>>>>> with can’t just send me a request to transfer $500 to some account. 
>>>> 
>>>> Are we talking about legal consent or a security measures here?
>>> 
>>> Normal OAuth consent. My phone is my resource, and I am its resource owner. 
>>> If a client wants to send payment requests to my phone (e.g. via CIBA 
>>> backchannel) then it should have to get my permission first. Even without 
>>> backchannel requests, I’d much rather that only the three clients I’ve 
>>> explicitly consented to can ask me to initiate payments rather than the 
>>> hundreds/thousands clients my bank happens to have a relationship with.
>> 
>> To me it sounds like you would like to require a client to get user 
>> authorization to send an authorization request. Would you require the same 
>> if I would use scope values to encode a payment initiation request?
> 
> Yes. If something is sufficiently high value to require per-transaction 
> authorization then initiating transactions itself becomes a privileged 
> operation. 

The per transaction authorization alone is a significant increase in security. 
What is the added value of requiring an authorization to send a per-transaction 
authorisation request in an additional step?

> 
>>>> 
>>>> In case of open banking the user legally consents to this process at the 
>>>> client (TPP) even before the OAuth/Payment Initiation dance starts. 
>>> 
>>> How does the bank (ASPSP) confirm that this actually happened?
>> 
>> It does not because it is not the responsibility of the ASPSP. The TPP is 
>> obliged by law to obtain consent.
> 
> If the TPP can be trusted to obey the law about this, why not also trust them 
> to be honest about transactions? Why enforce one thing with access tokens but 
> take the other on trust? Especially as the actual transactions are more 
> likely to have a rigorous audit trail. 
> 
> If we could trust clients to obtain consent we wouldn’t need OAuth at all. 

I thought the same initially, but we must distinguish between legal consent and 
strong authentication/transaction authorization in such a case. Legal consent 
can be obtained in various ways including the traditional OAuth user consent 
but also in other places. Authenticating the user (probably with 2FA) and 
getting authorization for a certain transaction (the meaning of PSD2 SCA) must 
be conducted by the AS. 

> 
> — Neil



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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> Am 08.07.2020 um 20:46 schrieb Neil Madden :
> 
> On 8 Jul 2020, at 19:03, Torsten Lodderstedt  
> wrote:
>>>> 
>>>> What in particular should the use consent with in this step?
>>> 
>>> “FooPay would like to:
>>> - initiate payments from your account (you will be asked to approve each 
>>> one)”
>>> 
>>> The point is that a client that I don’t have any kind of relationship with 
>>> can’t just send me a request to transfer $500 to some account. 
>> 
>> Are we talking about legal consent or a security measures here?
> 
> Normal OAuth consent. My phone is my resource, and I am its resource owner.. 
> If a client wants to send payment requests to my phone (e.g. via CIBA 
> backchannel) then it should have to get my permission first. Even without 
> backchannel requests, I’d much rather that only the three clients I’ve 
> explicitly consented to can ask me to initiate payments rather than the 
> hundreds/thousands clients my bank happens to have a relationship with.

To me it sounds like you would like to require a client to get user 
authorization to send an authorization request. Would you require the same if I 
would use scope values to encode a payment initiation request?

> 
>> 
>> In case of open banking the user legally consents to this process at the 
>> client (TPP) even before the OAuth/Payment Initiation dance starts. 
> 
> How does the bank (ASPSP) confirm that this actually happened?

It does not because it is not the responsibility of the ASPSP. The TPP is 
obliged by law to obtain consent.

> 
> — Neil


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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> On 8. Jul 2020, at 18:59, Neil Madden  wrote:
> 
> 
> 
>> On 8 Jul 2020, at 17:21, Torsten Lodderstedt  wrote:
>> 
>> 
>> 
>>> On 8. Jul 2020, at 18:17, Neil Madden  wrote:
>>> 
>>>> On 8 Jul 2020, at 15:40, Justin Richer  wrote:
>>>> 
>>>> The two-phase approach is exactly what OBUK does, where you get one access 
>>>> token using client credentials before getting a more specific one in 
>>>> context of the user’s consent. This ends up being awkward to implement at 
>>>> best, since OAuth involves the user too early in the process to allow for 
>>>> this kind of thing. PAR might help address this dichotomy, but RAR can 
>>>> provide places for this to fill in.
>>> 
>>> I’m not sure how client credentials would help here. The point I’m making 
>>> is that the _user_ needs to consent to two separate things:
>>> 
>>> 1. An initial consent to allow this app/service to initiate payment 
>>> requests on my behalf.
>> 
>> What in particular should the use consent with in this step?
> 
> “FooPay would like to:
> - initiate payments from your account (you will be asked to approve each one)”
> 
> The point is that a client that I don’t have any kind of relationship with 
> can’t just send me a request to transfer $500 to some account. 

Are we talking about legal consent or a security measures here?

In case of open banking the user legally consents to this process at the client 
(TPP) even before the OAuth/Payment Initiation dance starts. 

> 
>> 
>>> 2. Consent to individual transactions.
>>> 
>>> RAR (and open banking?) completely omits step 1 at the moment, which seems 
>>> crucial. Especially if you’re doing something like CIBA backchannel where 
>>> step 1 is effectively consent for this app to spam my phone with payment 
>>> approval requests.
>>> 
>>>> 
>>>> With XYZ, I tried to design for that kind of multi-stage transaction 
>>>> pattern more explicitly, with the idea that you could continue your 
>>>> request in context and vary it over time, or even start a new request in 
>>>> the context of an existing one. This is something that I intend to 
>>>> continue with the soon-to-be-formed GNAP working group, if you want to 
>>>> bring this use case there.
>>> 
>>> RAR is adopted by the OAuth WG so I think this needs to be discussed here.
>>> 
>>> — Neil
>>> ___
>>> 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] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> On 8. Jul 2020, at 18:17, Neil Madden  wrote:
> 
> On 8 Jul 2020, at 15:40, Justin Richer  wrote:
>> 
>> The two-phase approach is exactly what OBUK does, where you get one access 
>> token using client credentials before getting a more specific one in context 
>> of the user’s consent. This ends up being awkward to implement at best, 
>> since OAuth involves the user too early in the process to allow for this 
>> kind of thing. PAR might help address this dichotomy, but RAR can provide 
>> places for this to fill in.
> 
> I’m not sure how client credentials would help here. The point I’m making is 
> that the _user_ needs to consent to two separate things:
> 
> 1. An initial consent to allow this app/service to initiate payment requests 
> on my behalf.

What in particular should the use consent with in this step?

> 2. Consent to individual transactions.
> 
> RAR (and open banking?) completely omits step 1 at the moment, which seems 
> crucial. Especially if you’re doing something like CIBA backchannel where 
> step 1 is effectively consent for this app to spam my phone with payment 
> approval requests.
> 
>> 
>> With XYZ, I tried to design for that kind of multi-stage transaction pattern 
>> more explicitly, with the idea that you could continue your request in 
>> context and vary it over time, or even start a new request in the context of 
>> an existing one. This is something that I intend to continue with the 
>> soon-to-be-formed GNAP working group, if you want to bring this use case 
>> there.
> 
> RAR is adopted by the OAuth WG so I think this needs to be discussed here.
> 
> — Neil
> ___
> 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] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

Hi Neil, 

> On 8. Jul 2020, at 16:40, Justin Richer  wrote:
> 
> The two-phase approach is exactly what OBUK does, where you get one access 
> token using client credentials before getting a more specific one in context 
> of the user’s consent. This ends up being awkward to implement at best, since 
> OAuth involves the user too early in the process to allow for this kind of 
> thing. PAR might help address this dichotomy, but RAR can provide places for 
> this to fill in.
> 
> With XYZ, I tried to design for that kind of multi-stage transaction pattern 
> more explicitly, with the idea that you could continue your request in 
> context and vary it over time, or even start a new request in the context of 
> an existing one. This is something that I intend to continue with the 
> soon-to-be-formed GNAP working group, if you want to bring this use case 
> there.
> 
>  — Justin
> 
>> On Jul 6, 2020, at 12:32 PM, Neil Madden  wrote:
>> 
>> I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have some 
>> time, and I have a few comments.
>> 
>> An assumption in the draft appears to be that the client knows ahead of time 
>> what it wants to gain access to and can describe it in detail. For example, 
>> the last example in section 2.1 is a client requesting access to particular 
>> files, which assumes that the client already knows the paths of the files it 
>> wants to access. This in turn seems to imply that the client already has 
>> some level of access to be able to determine this, e.g. to list directories, 
>> which may not be desirable. In many cases like this I think it’s more 
>> natural for the client to not know exactly what it is asking for but instead 
>> to want access to *some* file, chosen by the user. An example of this is the 
>> Dropbox Chooser [1] and Saver [2] APIs, which notably are not built on top 
>> of OAuth. In these cases it would be more natural for the client to send a 
>> more generic request and for the details to be filled in by the user as part 
>> of the consent process.

That’s a very good point.

There are scenarios where the client knows the resources it wants to interact 
with in advance, potentially from another transaction (e.g. first access to 
account list, payment initiation afterwards). 

The scenario you are describing is viable as well. In such a case, the request 
would be fairly generic but the AS (or the RS) would need to make transparent 
to the client what resources it just obtained access for. Interestingly, this 
might also happen if the client wants to access accounts. It could just request 
access to accounts and the user, in the consent, selects the accounts to 
disclose to the client. In our design at yes, we reflect this in an augmented 
authorization_details object in the token response (an addition for the spec I 
have on my list). 

>> 
>> Another issue is that as far as I can see in the current draft, any client 
>> can initiate a rich authorization request at any time without any kind of 
>> prior approval. This seems problematic for the main example in the draft, 
>> i.e. payment initiation. As an attacker, if I can get a consent screen up on 
>> a user’s device requesting to move money around then it seems like half my 
>> job is already done - some fraction of users will probably approve such a 
>> transaction without properly checking it. It feels like the ability to ask 
>> for transaction approval should already be a privileged operation that 
>> should require consent and approval.

I think RAR will almost always be used in conjunction with PAR. This means the 
client is authenticated before the user interaction starts preventing the 
attack you mentioned. I think we should at least recommend this in the draft. 

>> 
>> A related issue is that each approval is in effect a completely isolated 
>> incident. In a normal OAuth2 interaction I would grant an app some 
>> longish-term access to data and it would get an access token and optionally 
>> a refresh token. At some later point I can go to the AS and see that I have 
>> granted this access and revoke it if I choose. With RAR there is no 
>> representation of a long-term relationship between the RO and the client and 
>> each transaction starts from fresh. Again, this seems potentially 
>> problematic and not quite in keeping with how OAuth currently operates. Each 
>> grant of access is ephemeral. (Do refresh tokens make sense in the context 
>> of RAR?)

Some of the use cases initially causing the development of RAR are 
transactional (as pointed out by Vladimir) others are not. RAR is about a 
richer vocabulary for describing the scope of access.

In the beforementioned account information scenario, the client would, for 
example, ask for read access to several accounts. Access to balance for one and 
access to balance & transaction history for another account. This could easily 
be expressed using RAR and would be a long term grant. If the client for the 
same user asks for