Just commenting on this part – I wanted to say during the call, but kept dropping
J
“How can a client dynamically add a scope that they didn't register for in the beginning? Or delete? Well, shouldn't that be for the client registration protocol to figure out? But if the
policy conditions have been satisfied, maybe the authorization assessment should still result in granting the permission with the scope requested.”
If dynamic client registration is used, a client can update and delete its configuration (which optionally includes a scope parameter).
About the AS assessment – in OAuth2 (RFC 6749) it says:
“ The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.”
“Different” may be understood as only scope reduction, but can it be seen also as scope expansion (if the policy allows)?
Upon a request, then AS can return a token with a wider set of scopes – which may amortize the cost for the client in its further interactions with the RS (Then, should the RS stay as just
“the messenger”? It just registers the permission for what is requested and does not try to expand the scope of the request).
I will respond separately also to set math, and use case question, which would probably make my point more clear.
Thanks,
--Cigdem
From:
<wg-uma-bounces@kantarainitiative.org> on behalf of Eve Maler <eve@xmlgrrl.com>
Date: Thursday, 1 December 2016 at 18:23
To: "wg-uma@kantarainitiative.org WG" <wg-uma@kantarainitiative.org>
Subject: [WG-UMA] Draft minutes of UMA telecon 2016-12-01
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01
Quorum was reached.
Approve minutes of UMA telecon 2016-11-10: Moved
by Andi, seconded by John: APPROVED by unanimous consent.
No meetings next week at all (no Dec 8 or Dec 9 meeting).
Dec 15 and Dec 16: regular meetings.
Dec 22: WG meeting. Dec 23: no Legal meeting.
Eve reviewed the "spec end game" timeline as shown above.
UMA's essential characterization: Previously we called it a profile. Now it's called a framework, including
mention of its extension grant. What's the right characterization? Though UMA has fewer MAYs and SHOULDs than OAuth, it's still general. Framework, application, extension, profile... Only profile is outright inaccurate if it's the only word used. John W suggests
"make use of" instead of "leveraging".
AI: Justin: Please look at the new Note wording in Core 09 Sec 1.4 to see if a) it's okay and b) this wording
could replace some instances of the wording that now appears in multiple places in the spec.
Set math: Eve left out a relevant step in her set math email; the set of scopes that the RS registered at the
AS could have a bearing on later steps. If the client only ever registered for n scopes out of m possible ones, then even if it later asks for more, the n scopes
are a hard mask/limiting factor. Registering for scopes is simply a part of client registration, so we don't have to talk about the mechanism at all, just the effects of it.
Today, clients register for scopes, and the scopes map in some relationship to resources (API calls/endpoints) determined by the API publisher (or the open API that the publisher adheres to). The
same is true of UMA, except that the relationship is reified in the RReg interface by virtue of the resource description document that is registered from RS to AS, through a resource ID. (Note that there is an I-D floated in the OAuth WG that has a similar
kind of resource ID...) What's weird is registering for scopes – which describe a strange universe of resources – vs specific resources or resource types or suchlike. Apparently the OAuth WG is discussing the latter as client registration upgrades.
How can a client dynamically add a scope that they didn't register for in the beginning? Or delete? Well, shouldn't that be for the client registration protocol to figure out? But if the policy
conditions have been satisfied, maybe the authorization assessment should still result in granting the permission with the scope requested.
Maybe we can "future-proof" against client registration getting smarter and allowing registration for resources or resource types or something.
AI: All: Please review and respond to the "Set
math discussion setup" email so we can decide key set math questions as expeditiously and thoroughly as possible.
Instructions:
·
Revise abstract and intro to account for characterization discussion.
·
Define "resource" as separate from "protected resource". Put an xref to the Sec 1.4.3 explanation about how an RS MAY manage complex resources.
As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)
1.
Domenico
2.
Sal
3.
Nagesh
4.
Andi
5.
Eve
6.
Mike
7.
Cigdem
8.
Sarah
Non-voting participants:
·
François
·
Justin
·
John W
·
George
·
Ariel – responsible for IAM and data protection at TIAA
·
Kathleen
·
Ishan
·
Scott S
Regrets:
·
Maciej
·
James
Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl