Hi George, > Am 22.06.2018 um 19:51 schrieb George Fletcher <gffle...@aol.com>: > > 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?
The access token is good for a certain transaction only. In case of a
electronic signature, the access token is bound to a certain document or a set
of documents.
>
> 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.
What would be the scope of such a refresh token?
>
> Maybe this is similar to what Nat is describing with the staging API?
The staging API represents the data of a certain transaction in a resource,
which allows to parametrize the scope just with the identifier of that
resource. So the transaction data can be transmitted in a robust fashion.
best regards,
Torsten.
>
> 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> 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
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
