Hi George,
I‘m intrigued by the idea to encapsulate scope preparation and resource
identification
into the RS. This seems to be a viable pattern to implement
transaction-oriented
authorization.
I‘m not sure whether this justifies the implementation of UMA 2.0 in AS
(additional
grant types,
Yes, that is the basic idea and matches the UMA flow. I think some profiling of
UMA is required but may be good place to start.
Thanks,
George
--
Identity Standards Architect
Identity Engineering
Oath
> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt
> wrote:
>
> Hi George,
>
> thanks a
Hi George,
thanks a lot for investing the time to assemble this flow description!
If I got it right the idea is to move the definition of the required
permissions (scope)
of the requested access token to the interaction between signing service and
authz service
when the permission ticket is ob
Hi George,
how is the dynamic nature (hash) of the authorization request handled in your
solution?
Note: the signing service is not provided by the insurance company but a third
party, a sol-called trusted service provider. The insurance company as the
client in this flow sends the request to
Thanks Torsten.
I think I have a solution :) Just to make sure I have the flow correct...
Assumption: Using a mobile client
1. User (using their mobile client) attempts to sign a document with the
insurance company
2. Insurance company redirects the user to their Bank asking for
identity proo
an intended recipient, please notify the sender and
> delete this e-mail.
> From: OAuth on behalf of Torsten Lodderstedt
>
> Sent: Saturday, June 23, 2018 3:43:50 AM
> To: George Fletcher
> Cc: Brian Campbell; oauth
> Subject: Re: [OAUTH-WG] Dynamic Scopes
>
>
.
From: OAuth on behalf of Torsten Lodderstedt
Sent: Saturday, June 23, 2018 3:43:50 AM
To: George Fletcher
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] Dynamic Scopes
> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>
> I would think that the scope issu
> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>
> I would think that the scope issued to the refresh_token could represent the
> category or class of authorizations the refresh_token should be able to
> perform. For example, the kind of transactions that can be bound to access
> tokens.
On 6/22/18 4:31 PM, Torsten Lodderstedt wrote:
Hi George,
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 addition
Hi George,
> Am 22.06.2018 um 19:51 schrieb George Fletcher :
>
> 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 thes
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
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
Hi Nat,
> Am 21.06.2018 um 10:35 schrieb Nat Sakimura :
>
> 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
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.
My preference by far is to set up a staging endpoint and
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
assum
Hi Jacob,
thanks for your thoughts on dynamic scopes.
> Am 19.06.2018 um 08:16 schrieb Jacob Ideskog :
>
> For OpenID I still think the signed claims parameters make a more flexible
> approach, but OpenID isn't always in play.
Why do you think it is more flexible?
kind regards,
Torsten.
This borderlines another problem we've been adressing which is when a
client needs to pass on the request to an asyncronous queue. In that case
the client can request the AS to "downscope" it's token, and include a
signature of the request in the token. (simplified).
The dynamic scope approach wou
One of the reasons I hear for people wanting parameterized scopes is to deal
with transactions. I’d love to hear thoughts from the group on if/how OAuth
should be used to authorize a transaction, vs authorize access to
information/actions for a period of time. This approach for instance sounds
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)
19 matches
Mail list logo
