Re: [OAUTH-WG] OAuth Digest, Vol 147, Issue 3

[이천욱 <[e-mail]>]

You send not mail please
Loose mail only
Please send not mail

2021년 1월 12일 (화) 오전 5:02, <[e-mail]>님이 작성:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Rich Authorization Requests feedbacks on implementation
>       (Nicolas Mora)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 10 Jan 2021 20:36:36 -0500
> From: Nicolas Mora <[e-mail]>
> To: oauth <[e-mail]>
> Subject: [OAUTH-WG] Rich Authorization Requests feedbacks on
>         implementation
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> I've implemented Rich Authorization Requests defined in
> draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I
> humbly wanted to write my feedback about this implementation to share my
> experience.
>
> For starters, this implementation and my following feedbacks are based
> on the prism of Glewlwyd's implementation and philosophy, and my limited
> experience on OAuth2, so I appologize in advance if I write non-sense or
> big mistakes.
>
> 1 - Design
>
> The way I saw it, there are 2 different approaches to implement oauth2
> rar: either to get a token with a more detailed scope, or to get a
> one-time token with extra grants.
>
> Both are not exclusive, but a big difference I see between those 2
> approaches is the grant access from the user part. The second approach
> would require the user to know what extra grant is asked by the client
> every time the client asks for it, i.e. when the client redirects the
> user to the /authorization endpoint.
>
> To be more consistent with Glewlwyd's philosophy, I chose the first
> approach, with those rules.
> The AS administrator declares what rar types are allowed [2]
>    - a rar type has a defined set of locations, actions, datatypes and
> enriched authorization details that the client can ask for
>    - the client must be explicitly allowed to add a rar type in the
> authorization request
>    - a rar type can be linked to one or more scope. In that case, the
> authorization request must include at least one of the linked scope, and
> the scope must be available for the user and the scope must be granted
> to the client
>    - the client can add as many properties as required in the rar type,
> those extra properties are not verified by the AS, on access granted,
> the extra properties will be present in the "authorization_details" result.
>
> On first use of a rar type by a client for a user, the user must grant
> to the client the rar access [3]. That's why the grant message will show
> to the user ALL access possible via this rar type
> Once this access is granted or not, the user will not be asked again on
> another authorization request by the client (but is can be changed at
> any time, as a scope grant).
>
> 2 - Limitations
>
> In this design, the AS has a limited control over the
> authorization_details content, and the trust between the AS and the
> client must be high enough so if a rar type can gain access to sensitive
> actions or information, the user should know about it.
>
> Also, in the draft specification, the only mandatory element type in a
> rar is the "type" element. In my point of view, this means that the
> business logic is mostly defined by the RS, rather than the AS.
>
> Therefore, for a client implementation to be compliant with the specs,
> there's not much to do: add as a parameter a JSON array with objects
> containing at least one "type" string property in it.
>
> 3 - Extensions
>
> I believe one way to mitigate these limitations is to allow extensions
> to be defined on top of the rar specifications. An extension can be
> declared like this:
>
> "RAR Extension XYZ:
> A rar whose type is XXX
> - Actions available: YYY, ZZZ or AAA
> - datatypes possibles: BBB, CCC, DDD or EEE
> - additional elements mandatory: an array of FFF and an object of GGG to
> represent access to some"
>
> Like this, if the AS, the RS and the client agree on using a rar
> extension, they can have at least a detailed pattern on what to expect
> in the rar type.
>
> Any thoughts?
>
> /Nicolas
>
> [1] https://github.com/babelouest/glewlwyd
> [2]
>
> https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/plugin-oidc-rar.png
> [3]
>
> https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/login-rar-grant.png
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 147, Issue 3
> *************************************
>