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

[Saxe, Dean]

+1 – I support adoption.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO (he/him)
Senior Security Engineer, AWS Identity Trust Team | Amazon Web Services (AWS)
E: deans...@amazon.com | M: 
206-659-7293

From: OAuth  on behalf of Rifaat Shekh-Yusef 

Date: Tuesday, November 15, 2022 at 6:44 AM
To: oauth 
Subject: [EXTERNAL] [OAUTH-WG] Call for adoption: Cross-Device Flows


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


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

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

[Tobias Looker]

+1 I support adoption of this draft.


Thanks,

[Mattr 
website]



Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker@mattr.global

[Mattr 
website]

[Mattr on 
LinkedIn]

[Mattr on 
Twitter]

[Mattr on 
Github]

This communication, including any attachments, is confidential. If you are not 
the intended recipient, you should not read it - please contact me immediately, 
destroy it, and do not copy or use any part of this communication or disclose 
anything about it. Thank you. Please note that this communication does not 
designate an information system for the purposes of the Electronic Transactions 
Act 2002.


From: OAuth  on behalf of Torsten Lodderstedt 

Sent: 23 November 2022 00:28
To: Justin Richer 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click 
links or open attachments unless you recognise the sender and know the content 
is safe.

+1 I support adoption of this draft.

Am 22.11.2022 um 01:44 schrieb Justin Richer 
mailto:jric...@mit.edu>>:

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 
mailto:rifaat.s.i...@gmail.com>> 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] 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

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

[internet-drafts]

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

Title   : OAuth 2.0 Rich Authorization Requests
Authors : Torsten Lodderstedt
  Justin Richer
  Brian Campbell
  Filename: draft-ietf-oauth-rar-16.txt
  Pages   : 46
  Date: 2022-11-22

Abstract:
   This document specifies a new parameter authorization_details that is
   used to carry fine-grained authorization data in OAuth messages.


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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-16.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-16


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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