Transaction Authorization or why we need to re-think OAuth scopes

[Basney, Jim]

Hi all,

In case you haven't already seen it, I recommend the post "Transaction Authorization or why we need to re-think OAuth scopes" by Torsten Lodderstedt and the follow-up by Nat Sakimura:

https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

https://nat.sakimura.org/2019/05/12/comments-back-to-transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-by-torsten/

In SciTokens we have been using the simple OAuth scope to accommodate capabilities of the form $AUTHZ:$PATH like "read:/foo".

The more structured approaches described by Torsten may be very helpful as SciTokens expands into more advanced use cases.

Interested in any thoughts/comments y'all might have on it.

Regards,
Jim

[Brian Bockelman]

Hi Jim,

I was just lamenting today to Todd -- it's a bit crazy that OAuth
forces us to pass scope names around as space-separated strings when,
in reality, everything else in the ecosystem is based on JSON and has
a perfectly reasonable way to structure requests.

That being said, there is some value to simplicity. In the WLCG
discussions, a few folks have brought up "why substring matching for
resource names? Why not allow Unix globs? Java globs?
Perl-compatible regexs? POSIX regex?" The response is typically
"keep it simple -- do we have any use cases that need more complex
structures?"

If you think of data or compute access, where do you think a
structured scope would help?

Brian

> --
> You received this message because you are subscribed to the Google Groups "SciTokens Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@scitokens.org.

[Mischa Salle]

Hi Jim, Brian,

interesting posts!
I do appreciate Nat's subtle remark that the 'structured_scope' is
already there, i.e. the 'claims' parameter. The reason we all went for
scope-per-claim was the lack of support for the 'claims' request (being
optional). Introducing yet another, but even less supported
structured_scope parameter seems like going back to where we started.
I'm actually wondering, when implementing the type of 'fat' scopes we're
now introducing, such as 'read:/foo', doesn't that likewise require
changes in both server and client, i.e. couldn't we have used the claims
request?

Mischa

--
Nikhef Room H155
Science Park 105 Tel. +31-20-592 5102
1098 XG Amsterdam Fax +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..