Hi Torsten,
Re: using request object
Carrying the scope parameter in the request object solves the integrity
issue. However, it does not solve the confidentiality issue unless you also
encrypt it, and encryption is not so easy.
Re: 2 extra roundtrips
You can actually cut the extra roundtrips to one. In fact, you probably
want to have the staging object to be signed to have it work as an evidence
when something goes wrong, so you could rely on that for the client
authentication purpose and that will be more efficient, IMHO. Yes, that
will become essentially the request_uri model.
Cheers,
Nat
2018年6月22日金曜日、Torsten Lodderstedt<tors...@lodderstedt.net>さんは書きました:
> Hi Nat,
>
> > Am 21.06.2018 um 10:35 schrieb Nat Sakimura <sakim...@gmail.com>:
> >
> > It depends on the use case but if you are talking about payment etc.,
> putting the transaction details in the scope and sending it over the
> regular RFC6749 redirect to the authorization server is inherently a bad
> idea, as it is not protected.
>
> Good point. One could carry the scope parameter as part of a signed
> request object to cope with that issue. What do you think about that?
>
> >
> > My preference by far is to set up a staging endpoint and push the
> transaction intent into there. Then, do the authorization on that staged
> transaction. Once that's done. I am OK with putting the reference to the
> staged transaction in the scope parameter.
> >
> > The beauty of the "staging" strategy is that:
> >
> > 1) You can push pretty big payload to the staging endpoint as it is a
> server to server thing;
> > 2) You can do the "auth" and then later "capture" after shipping the
> product strategy using the access token the client has obtained;
> > 3) The content of the transaction is not exposed via URL nor referrers.
>
> I agree. That’s really powerful. But one should also admit the client
> needs to prepare and send two more requests. In OB UK the client first
> obtains an access token using the client credentials grant and then creates
> the payment/account information resource.
>
> best regards,
> Torsten.
>
> >
> > Best,
> >
> > Nat
> >
> >
> >
> > On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell <bcampbell=
> 40pingidentity....@dmarc.ietf.org> 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
> > --
> > Nat Sakimura
> >
> > Chairman of the Board, OpenID Foundation
> >
>
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
