So here is my attempt at a simple example:
Lets assume that Alice is using photos.example.com (RS) to manage her
photos and copmonkey.example.com (UMA AS) to protect her photos. Bob wants
to access Alice's landscape photo album (
photos.example.com/photos/alice/landscape). Bob uses the myPhotos app
(Client).
scopes registered by myPhotos at AS registration time
ClientReg = (view, download, print)
ClientRegisteredDefaults = (view)
[Note, I don't believe the OAuth2 dynamic client registration allows
for registering defaults, but I'm including it because it's part of this
thread.]
scopes registered by photos.example.com for Alice's landscape photos
resource set
RSReg = (view, share, download, print)
[resource set id = 1234]
Alice defines policy for the registered scopes for her landscape photos
view = promise not to steal
share = promise not to steal
download = family members only
print = NOT ALLOWED
ROPolicy = (view, share, download)
Bob's myPhotos app attempts to access
photos.example.com/photos/alice/landscape and receives back a permission
ticket that identifies scopes (view, share). The app presents the
permission ticket to the token endpoint along with scopes (print, resale).
RSTicket = (view, share)
ClientReq = (print, resale)
[I'm going to ignore the PrevRPT because I think is has some issues unless
defined in a very particular way.]
So, now that all the sets are defined we can apply the set math:
Requested = union(intersection(ClientReq,ClientReg), RSTicket,
ClientRegisteredDefaults)
Requested =
union(intersection((print,resale),(view,download,print)),(view,share),(view))
Requested = (view,share,print)
Evaluating the policy defined for the registered resource set id:1234,
Alice and prohibited the use of the print scope. So the ROPolicy is limited
to (view,share,download).
To determine which claims Bob must meet, we have to determine which scopes
are in play for resource set id:1234
Scopes = intersection(Requested, ROPolicy)
Scopes = intersection((view,share,print),(view,share,download))
Scopes = (view,share)
Bob meets the necessary claims for scopes (view,share) as defined by the
Alice's policy for the 'view' and 'share' scopes on her landscape photos.
Bob's myPhotos app is granted an RPT that allows for (view,share) for
resource set id:1234
RPTResult = RSID_1234(view,share)
Please check the math! :)
To try an simplify the steps, for each /token call with uma grant
1. Determine the set of requested scopes
1. Requested = union( intersection(ClientReq,ClientReg), RSTicket,
ClientRegisteredDefaults)
2. Determine the set of scopes allowed by the Resource Owner
1. Evaluate the policy for the identified resource set(s) and
determine if any of the registered scopes are not allowed
2. ROPolicy = list of scopes allowed by RO
3. Determine the set of scopes for which RqP must meet claims in order
to receive an RPT
1. Scopes = intersection (Requested,ROPolicy)
4. Determine the set of claims necessary for Scopes as they pertain to
the specified resource set(s)
1. Claims = union(resource_set_claims(rsid,scopes))
5. Request RqP to meet Claims
6. Assuming RqP meets Claims, issue RPT
Thanks,
George
P.S. Note that I think in step 3 we really want two sets of scopes.
RequiredScopes and AdditionalScopes as it's possible for the RqP to meet
the claims of the scopes in the RSTicket but not the possible additional
scopes. This would look like...
RequiredScopes = intersection(RSTicket,ROPolicy)
AdditionalScopes =
intersection(difference(Requested,RSTicket),ROPolicy)
On Wed, Jan 11, 2017 at 7:31 PM Eve Maler
I have to admit you guys have now gone beyond my ability to follow. :-) If someone could summarize in English pseudo-spec language, and a simple example, I would be very very grateful. I would like any discussion of this tomorrow to to be efficient, because there's lots of other stuff to discuss too.
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Tue, Jan 10, 2017 at 2:02 PM, James Phillpotts < james.phillpotts@forgerock.com> wrote:
Well, in fact I was suggesting:
Requested = union(intersection(ClientReg, ClientReq), RSTicket, ClientRegisteredDefaults)
But I can live with ClientRegisteredDefaults being an off-spec AS extension, so yes :)
Cheers James
On 10 January 2017 at 19:16, George Fletcher
wrote: Yes, though I'd feel better with James weighing in to make sure I understood his idea correctly:)
On Tue, Jan 10, 2017 at 2:08 PM Justin Richer
wrote: Interesting thought — so are you suggesting that:
Requested = union(intersection(ClientReg, ClientReq), RSTicket)
That would let ClientReg be a limiting set but wouldn’t leave out the RS requesting more scopes (or policies granting more scopes) than the client itself asked for.
I could live with that interpretation.
— Justin
On Jan 10, 2017, at 12:01 PM, George Fletcher
wrote: I personally don't have any issues making the client be explicit about it's requests, so I'd prefer to not have a default option at all and just have the client request what it wants at each RPT/Token request. This would then cause the ClientReg set to just be a limiting set on what the client can request at run time.
Note that the AS is free to not allow all the scopes requested in the ClientReg set at registration time, in which case the limiting set gets smaller. If that happens, then the only way the client can get a particular scope needed to access a resource is if that scope is identified by the permission ticket.
On Tue, Jan 10, 2017 at 11:57 AM James Phillpotts < james.phillpotts@forgerock.com> wrote:
Yes, exactly. The RS's permission ticket-requested scope values are incontrovertible. The registered scopes should only apply to whatever the Client is trying to request on top of that.
So my proposal is that the scope value in the client registration should be a restriction for what it can request in that vein (as RFC 7591 specifies it). A separate field, default_scope, could be added for what might get added by default. So I guess I'm suggesting a sort of hybrid of Option 2 and Option 3 from the minutes from last week's meeting.
Cheers James
On 10 January 2017 at 16:32, George Fletcher
wrote: So how do you want to apply the "superset" thinking to the scopes requested by the client at registration time? Are you thinking that the client can only explicitly requests scopes that are within that set? even though the permission ticket my expand the set beyond that?
Thanks, George
On Tue, Jan 10, 2017 at 11:23 AM James Phillpotts < james.phillpotts@forgerock.com> wrote:
Like I said, I'm talking about scope values requested by the client, *not* by the RS in the permission ticket.
J.
On 10 January 2017 at 16:21, George Fletcher
wrote: Hi James,
I guess what I'm saying is that even if the client registers for scopes A, B, C, and F; that doesn't prohibit the client from in fact requesting for scope K (as identified by the RS as required for the requested resource) when requesting a new RPT.
So in that sense, the list of client registered scopes can not be considered the super set of all scopes the client can request (which is what I thought you were saying in your email; again I probably misunderstood your intent:)
Thanks, George
On Tue, Jan 10, 2017 at 10:45 AM James Phillpotts < james.phillpotts@forgerock.com> wrote:
Hi George,
I'm not sure I understand you - we're talking here about scope values that the client knows about itself, registers for, and can be requested separately from those that are in the permission ticket. As such, a degree of static-ness can be assumed, in the same way as it is in vanilla OAuth.
Cheers James
On 9 January 2017 at 22:51, George Fletcher
wrote: Hi James,
I may have misunderstood, but I don't think with UMA there is anyway to say a client can only ask for scopes within this "set". (referencing your last paragraph).
Because of the dynamic nature of scopes and permissions tickets, a key capability of a client within UMA is the ability to get access to a resource that requires a scope the client has never even "seen" before. The key to be able to get authorized for this new scope is the ability to mean the ROPolicy for the requested resource. If the client/RqP can meet the required policy, then the RPT is granted the associated scope(s).
I can envision an AS defining a "black list" of scopes that a particular client could NEVER be authorized for, but this seems AS specific and out of scope for UMA.
Thanks, George
On Mon, Jan 9, 2017 at 4:06 AM James Phillpotts < james.phillpotts@forgerock.com> wrote:
This seems well thought out, thanks Justin. I've got just one concern:
I'm uneasy about using the client registered scopes as 'default scopes' in the case of UMA, when RFC7591 states that registered scopes represent "scope values that the client can use when requesting access tokens" - as you stated in Thursday's call. I'm particularly concerned about how any of this plays out when the client is trying to be both a vanilla OAuth (or OpenID Connect) client as well as an UMA client. If the client registers for scopes "openid profile view edit", then they must explicitly request openid and profile scope values in the token request in order to get an access token that contains those scopes, but if they present a permission ticket as well, we're saying they view and edit will automatically get evaluated/added without the client knowing about it.
I would prefer that we submit an extra 'default_scope' attribute to the OAuth Dynamic Client Registration Metadata Registry ( https://tools.ietf.org/html/rfc7591#section-4) to disambiguate from the existing 'scope' field. The client could then register with scope "openid profile edit" and default_scope of "view".
This also has an extra advantage of being able to use the registered scope field to block requests for scope values that have not been registered for the client - i.e. client registers for scope A, has a permission ticket for scope B, but requests scope C in the token request, which should then result in an 'invalid_scope' response.
Cheers James
On 8 January 2017 at 21:05, Justin Richer
wrote: -- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 Office:+1-703-265-2544