I like the concept of parameterized scopes but I'm not sure they should
be used for per-transaction use cases. It seems like the use cases
presented are about operating on parameters specific to the transaction.
Why are these part of the authorization flow?
Is the goal to bind an access token to a particular transaction? If this
is the case, would it not be better to either extend the refresh_token
flow or may better yet, create a new grant_type that takes the
refresh_token and additional "binding" parameters and then have that
return the "bound" access token to be used for the transaction.
Maybe this is similar to what Nat is describing with the staging API?
Thanks,
George
On 6/20/18 5:58 PM, Brian Campbell wrote:
In my own personal and humble opinion, Torsten, what you describe as
"(1) Parameter is part of the scope value" is the most natural
approach and works without needing changes to, or going outside of,
RFC6749 The OAuth 2.0 Authorization Framework. There may be AS
implementations that have made assumption about scope values being
static (I know of at least one!) but that's an implementation/feature
issue, which can change, and not a spec issue.
The OIDC "claims" parameter is already a bit of a hairy beast and I
think using it and the ID Token to convey more dynamic
access/authorization is blurring the line between authorization and
authentication a bit much. Also, as others have pointed out, OIDC
isn't always in play - particularly for regular old authorization cases.
An additional query parameter might be simple for a one-off case but
it's nonstandard and not very repeatable.
On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Hi all,
I have been working lately on use cases where OAuth is used to
authorize transactions in the financial sector and electronic
signing. What I learned is there is always the need to pass
resource ids (e.g. account numbers) or transaction-specific values
(e.g. amount or hash to be signed) to the OAuth authorization
process to further qualify the scope of the requested access token.
It is obvious a static scope value, such as „payment“or „sign“,
won’t do the job. For example in case of electronic signing, one
must bind the authorization/access token to a particular document,
typically represented by its hash.
I would like to get your feedback on what you consider a good
practice to cope with that challenge. As a starting point for a
discussion, I have assembled a list of patterns I have seen in the
wild (feel free to extend).
(1) Parameter is part of the scope value, e.g.
„sign:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - I
think this is an obvious way to represent such parameters in
OAuth, as it extends the scope parameter, which is intended to
represent the requested scope of an access token. I used this
pattern in the OAuth SCA mode in Berlin Group's PSD API.
(2) One could also use additional query parameter to add further
details re the requested authorization, e.g.
GET /authorize?
.....
&scope=sign
.....
&hash_to_be_signed=<hash_to_be_signed>
It seems to be robust (easier to implement?) but means the scope
only represents the static part of the action. The AS needs to
look into a further parameter to fully understand the requested
authorization.
(3) Open Banking UK utilizes the (OpenID Connect) „claims“
parameter to carry additional data.
Example:
"claims": {
"id_token": {
"acr": {
"essential": true,
"value": "..."
},
"hash_to_be_signed": {
"essential": true,
"value": "<hash_to_be_signed>"
}
},
"userinfo": {
"hash_to_be_signed": {
"essential": true,
"value": "<hash_to_be_signed>"
}
}
}
I‘m looking forward for your feedback. Please also indicated
whether you think we should flush out a BCP on that topic.
kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<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
