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>
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
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
