[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&source=gmail-imap&ust=162170845500&usg=AOvVaw3AD80Xsr4FKahwS02BL42V
> Status: 
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/&source=gmail-imap&ust=162170845500&usg=AOvVaw0QU88gwZS5gDXDrwsKl1Qh
> Html:   
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html&source=gmail-imap&ust=162170845500&usg=AOvVaw3WCjco3EC1DVEPNMPDls7g
> Htmlized:   
> https://www.google.com/url?q=https://tools.ietf.org/html/draft-ietf-oauth-rar-05&source=gmail-imap&ust=162170845500&usg=AOvVaw16dhK0NC7iMgY_bSGklxXQ
> Diff:   
> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-05&source=gmail-imap&ust=162170845500&usg=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

[OAUTH-WG] I-D Action: draft-ietf-oauth-rar-05.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-05.txt
Pages   : 43
Date: 2021-05-15

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 is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

[Evert Pot]

On 2021-05-15 11:35 a.m., Filip Skokan wrote:

Hello Vittorio, Brian, everyone

This is a followup to my feedback in the TMI BFF interim meeting on 
April 26th where I mentioned I'd bring this to the list for discussion.


I proposed an alternative to using fixed endpoint locations and/or 
discovery. HTML  Tags .


These would be in the returned page HTML's head tag, e.g.





The javascript SDK handing TMI BFF would know to look for these 
defined meta tags to source the location of the different endpoints. I 
think this could be the primary place an SDK would look at as it 
doesn't require any upfront external requests.


For the SDK this is as simple as

var bffTokenPath =
document.querySelector('meta[name="oauth-bff-token"]').content;


If this was the only mechanism defined by the document (to be bashed) 
I think it can save the group a lot of time defining a client 
discovery document which would be otherwise needed. If discovery as an 
alternative solution is indeed inevitable, it can be a second in line 
mechanism the javascript SDK would know to use.


As discussed in the interim, a well known set of endpoints (or even a 
single root client discovery document) might not always be available 
for control to the webpage depending on where and how it is hosted, on 
the other hand the HTML it serves always, I hope, is.


A more appropriate HTML tag might be the  tag.

You would just need to register a link relationship in the IANA registry:

https://www.iana.org/assignments/link-relations/link-relations.xhtml

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

Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

[Dick Hardt]

As I said in the meeting, I think this is an interesting idea that is worth
exploring.

I don’t think we need to resolve this for WG adoption of the document.

On Sat, May 15, 2021 at 8:36 AM Filip Skokan  wrote:

> Hello Vittorio, Brian, everyone
>
> This is a followup to my feedback in the TMI BFF interim meeting on April
> 26th where I mentioned I'd bring this to the list for discussion.
>
> I proposed an alternative to using fixed endpoint locations and/or
> discovery. HTML  Tags .
>
> These would be in the returned page HTML's head tag, e.g.
>
> 
>> 
>
>
> The javascript SDK handing TMI BFF would know to look for these defined
> meta tags to source the location of the different endpoints. I think this
> could be the primary place an SDK would look at as it doesn't require any
> upfront external requests.
>
> For the SDK this is as simple as
>
> var bffTokenPath =
>> document.querySelector('meta[name="oauth-bff-token"]').content;
>
>
> If this was the only mechanism defined by the document (to be bashed) I
> think it can save the group a lot of time defining a client discovery
> document which would be otherwise needed. If discovery as an alternative
> solution is indeed inevitable, it can be a second in line mechanism the
> javascript SDK would know to use.
>
> As discussed in the interim, a well known set of endpoints (or even a
> single root client discovery document) might not always be available for
> control to the webpage depending on where and how it is hosted, on the
> other hand the HTML it serves always, I hope, is.
>
> Best,
> *Filip Skokan*
> ___
> 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] TMI BFF - html meta tags over/alternative to discovery

[Filip Skokan]

Hello Vittorio, Brian, everyone

This is a followup to my feedback in the TMI BFF interim meeting on April
26th where I mentioned I'd bring this to the list for discussion.

I proposed an alternative to using fixed endpoint locations and/or
discovery. HTML  Tags .

These would be in the returned page HTML's head tag, e.g.


> 


The javascript SDK handing TMI BFF would know to look for these defined
meta tags to source the location of the different endpoints. I think this
could be the primary place an SDK would look at as it doesn't require any
upfront external requests.

For the SDK this is as simple as

var bffTokenPath =
> document.querySelector('meta[name="oauth-bff-token"]').content;


If this was the only mechanism defined by the document (to be bashed) I
think it can save the group a lot of time defining a client discovery
document which would be otherwise needed. If discovery as an alternative
solution is indeed inevitable, it can be a second in line mechanism the
javascript SDK would know to use.

As discussed in the interim, a well known set of endpoints (or even a
single root client discovery document) might not always be available for
control to the webpage depending on where and how it is hosted, on the
other hand the HTML it serves always, I hope, is.

Best,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth