- WG-UMA - mailman.kantarainitiative.org

None
by None 01 Dec '16

01 Dec '16

by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uB1MHES2030033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Dec 2016 17:17:16 -0500 To: Mike Schwartz <mike(a)gluu.org>, wg-uma(a)kantarainitiative.org References: <69fa5e4e659e6ef5352a7a141dc82ec4(a)gluu.org> From: Justin Richer <jricher(a)mit.edu> Message-ID: <e2f9b8e1-c29d-d66a-8977-7bff158b35b8(a)mit.edu> Date: Thu, 1 Dec 2016 17:17:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <69fa5e4e659e6ef5352a7a141dc82ec4(a)gluu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrJu70CHC4NNyEYs5r5axWUw+9pnF gclj/SV/j1WbO9kCmKK4bFJSczLLUov07RK4Mt5dm8ZWcFG9Yv3Mw4wNjI/luxg5OSQETCRu 9x5l7mLk4hASaGOSOHj3LxOEs4FRomPlXUYI5zaTxN4f55lAWoQFtCQu/JzF0sXIwSEiYC/R 980AJCwkYC5x7Ox1dhCbTUBVYvqaFrByXgEriQevLrGB2CwCKhIPb80CqxEViJH4tO4vO0SN oMTJmU9YQGxOAQuJ9Xvfg9UzC9hK3Jm7mxnClpfY/nYO8wRG/llIWmYhKZuFpGwBI/MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoHBkd1HawTjxn9chRgEORiUe3hfGDhFC rIllxZW5hxglOZiURHkf6QGF+JLyUyozEosz4otKc1KLDzFKcDArifDmLQDK8aYkVlalFuXD pKQ5WJTEeRncv4YLCaQnlqRmp6YWpBbBZGU4OJQkeP/OB2oULEpNT61Iy8wpQUgzcXCCDOcB Gu4INry4IDG3ODMdIn+KUZdj2rPFT5mEWPLy81KlxHm3ghQJgBRllObBzQGlkYS3h01fMYoD vSXMexBkHQ8wBcFNegW0hAloScd1e5AlJYkIKakGRjbusKP5T5pTxZ/ZqD5j2xbh8Ktm9txD O0rC3Gd6StrLGtraKBb+mHg4utDhk9/txAILuSPPuq9YqP08W1NfJ8n69MGGty2Mh5wt+hTL X+lGxZzp/HK4oX6qh6x8UgvvgjUHNcQkLQ+lT9GJ9Ldj47KcXMnMK78oK0P1X7VC0RyWMkdG nhYlluKMREMt5qLiRABXPxkX/gIAAA== Subject: Re: [WG-UMA] Profile v. Framework X-BeenThere: wg-uma(a)kantarainitiative.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the User Managed Access WG mail list." <wg-uma.kantarainitiative.org> List-Unsubscribe: <http://kantarainitiative.org/mailman/options/wg-uma>, <mailto:wg-uma-request@kantarainitiative.org?subject=unsubscribe> List-Archive: <http://kantarainitiative.org/pipermail/wg-uma/> List-Post: <mailto:wg-uma@kantarainitiative.org> List-Help: <mailto:wg-uma-request@kantarainitiative.org?subject=help> List-Subscribe: <http://kantarainitiative.org/mailman/listinfo/wg-uma>, <mailto:wg-uma-request@kantarainitiative.org?subject=subscribe> X-List-Received-Date: Thu, 01 Dec 2016 22:17:18 -0000 The definition that I quoted today and I believe to be correct is found in RFC3339 (among other locations): The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. That is to say, a "conformant subset". This is pretty consistent with the use of "profile" in the world of standards definitions. (Please don't conflate the discussion with unrelated uses of the same word, like "racial profiling".) From your own examples, both SAML profiles and OIDC *do* specify subsets of functionality of the protocols that they profile. For SAML, the profiles take from the large swath of possible expressions in the SAML language to solve specific cases. These profiles fully conform to the SAML language and yet use a subset of said language in specific ways to get things done. From the OIDC case, it doesn't use the client credentials or resource owner credentials grant types, at all. But everything that it *does* do is conformant with OAuth. OIDC also provides additional functionality because it is its own protocol and not solely a profile of OAuth 2. Instead, it would be correct to say that OIDC *contains* a profile of OAuth 2 that limits decisions choices and functionality without breaking the underlying protocol. UMA does no such limiting, either in v1.x or current 2.x directions. In fact, UMA extends, uses, and builds upon OAuth. None of those are profiling activities. Could UMA contain a profile of OAuth 2 if it wanted to? Sure! But it doesn't -- it says "go use OAuth in these places" and "extend OAuth in these ways". In no place does it say "don't use this bit of OAuth". Yes, it's true that profiles can themselves be profiled. But just because something can be profiled does not mean that it is itself a profile, right? And if you look at UMA, so many things are so loose (claims gathering, anyone?) that it's way more open than OAuth in terms of decisions. I think "application protocol" or "framework" are appropriate here. I'm particularly sensitive to the language choice here because I once had to untangle a client who was convinced that UMA had fewer choices to make at runtime than OAuth, and as we all know that's simply not even remotely the case. This stemmed from UMA 1.x calling itself a "profile" of OAuth and the client in question interpreting that in the common fashion of "conformant subset". Once we showed them all of the ways that UMA inherits OAuth's flexibility and then adds its own on top, they realized that they had the wrong picture of the world. If we can keep people from coming up with that incorrect picture in the first place, I think it's our responsibility to do so. -- Justin On 12/1/2016 2:29 PM, Mike Schwartz wrote: > > Regarding today's discussion of "framework" versus "profile": > > The SAML profiles document states: "This document specifies profiles > that define the use of SAML assertions and request-response messages > in communications protocols and frameworks, as well as profiles that > define SAML attribute value syntax > and naming conventions." In the SAML sense, a profile is used to > "implement a scenario". For example, the XACML SAML profile > "facilitates this mapping by standardizing naming, value syntax, and > additional attribute metadata." > > Section 1 of OpenID Connect Core Spec: "Notably, without profiling > OAuth 2.0, it is incapable of providing information about the > authentication of an End-User" > > Of course OpenID Connect is also a superset of OAuth 2.0. There are > +/- 50 IANA registrations for OpenID COnnect: > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml > Plus, OpenID Connect defines the id_token and Hybrid Flow, which are > obviously not specified in OAuth 2.0. Can OpenID Connect be futher > profiled... of course. But certainly it provides a mapping of OAuth > 2.0 to implement a specific use case--a sign-in flow. Many times I've > heard of OpenID Connect being referred to as a profile by other > authors of the spec. > > So the idea that a profile is a "subset" of functionality is absurd. A > profile makes something more specific by elaborating on the details. > And the profile itself may still be generic--hence our aversion to > racial profiling. > > The fact is, OAuth 2.0 is a generic framework that provides a common > denominator that is useful for many applications. Clearly UMA has a > specific application in mind, tries to align with OAuth 2.0, and thus > IS a profile. The fact that it can be futher profiled does mean that > it cannot itself be a profile. > > - Mike > > > > > > ------------------------------------- > Michael Schwartz > Gluu > Founder / CEO > mike(a)gluu.org > http://support.gluu.org > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma

1 0

None
by None 01 Dec '16

01 Dec '16

by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uB1MHES2030033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Dec 2016 17:17:16 -0500 To: Mike Schwartz <mike(a)gluu.org>, wg-uma(a)kantarainitiative.org References: <69fa5e4e659e6ef5352a7a141dc82ec4(a)gluu.org> From: Justin Richer <jricher(a)mit.edu> Message-ID: <e2f9b8e1-c29d-d66a-8977-7bff158b35b8(a)mit.edu> Date: Thu, 1 Dec 2016 17:17:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <69fa5e4e659e6ef5352a7a141dc82ec4(a)gluu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrJu70CHC4NNyEYs5r5axWUw+9pnF gclj/SV/j1WbO9kCmKK4bFJSczLLUov07RK4Mt5dm8ZWcFG9Yv3Mw4wNjI/luxg5OSQETCRu 9x5l7mLk4hASaGOSOHj3LxOEs4FRomPlXUYI5zaTxN4f55lAWoQFtCQu/JzF0sXIwSEiYC/R 980AJCwkYC5x7Ox1dhCbTUBVYvqaFrByXgEriQevLrGB2CwCKhIPb80CqxEViJH4tO4vO0SN oMTJmU9YQGxOAQuJ9Xvfg9UzC9hK3Jm7mxnClpfY/nYO8wRG/llIWmYhKZuFpGwBI/MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoHBkd1HawTjxn9chRgEORiUe3hfGDhFC rIllxZW5hxglOZiURHkf6QGF+JLyUyozEosz4otKc1KLDzFKcDArifDmLQDK8aYkVlalFuXD pKQ5WJTEeRncv4YLCaQnlqRmp6YWpBbBZGU4OJQkeP/OB2oULEpNT61Iy8wpQUgzcXCCDOcB Gu4INry4IDG3ODMdIn+KUZdj2rPFT5mEWPLy81KlxHm3ghQJgBRllObBzQGlkYS3h01fMYoD vSXMexBkHQ8wBcFNegW0hAloScd1e5AlJYkIKakGRjbusKP5T5pTxZ/ZqD5j2xbh8Ktm9txD O0rC3Gd6StrLGtraKBb+mHg4utDhk9/txAILuSPPuq9YqP08W1NfJ8n69MGGty2Mh5wt+hTL X+lGxZzp/HK4oX6qh6x8UgvvgjUHNcQkLQ+lT9GJ9Ldj47KcXMnMK78oK0P1X7VC0RyWMkdG nhYlluKMREMt5qLiRABXPxkX/gIAAA== Subject: Re: [WG-UMA] Profile v. Framework X-BeenThere: wg-uma(a)kantarainitiative.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the User Managed Access WG mail list." <wg-uma.kantarainitiative.org> List-Unsubscribe: <http://kantarainitiative.org/mailman/options/wg-uma>, <mailto:wg-uma-request@kantarainitiative.org?subject=unsubscribe> List-Archive: <http://kantarainitiative.org/pipermail/wg-uma/> List-Post: <mailto:wg-uma@kantarainitiative.org> List-Help: <mailto:wg-uma-request@kantarainitiative.org?subject=help> List-Subscribe: <http://kantarainitiative.org/mailman/listinfo/wg-uma>, <mailto:wg-uma-request@kantarainitiative.org?subject=subscribe> X-List-Received-Date: Thu, 01 Dec 2016 22:17:18 -0000 The definition that I quoted today and I believe to be correct is found in RFC3339 (among other locations): The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. That is to say, a "conformant subset". This is pretty consistent with the use of "profile" in the world of standards definitions. (Please don't conflate the discussion with unrelated uses of the same word, like "racial profiling".) From your own examples, both SAML profiles and OIDC *do* specify subsets of functionality of the protocols that they profile. For SAML, the profiles take from the large swath of possible expressions in the SAML language to solve specific cases. These profiles fully conform to the SAML language and yet use a subset of said language in specific ways to get things done. From the OIDC case, it doesn't use the client credentials or resource owner credentials grant types, at all. But everything that it *does* do is conformant with OAuth. OIDC also provides additional functionality because it is its own protocol and not solely a profile of OAuth 2. Instead, it would be correct to say that OIDC *contains* a profile of OAuth 2 that limits decisions choices and functionality without breaking the underlying protocol. UMA does no such limiting, either in v1.x or current 2.x directions. In fact, UMA extends, uses, and builds upon OAuth. None of those are profiling activities. Could UMA contain a profile of OAuth 2 if it wanted to? Sure! But it doesn't -- it says "go use OAuth in these places" and "extend OAuth in these ways". In no place does it say "don't use this bit of OAuth". Yes, it's true that profiles can themselves be profiled. But just because something can be profiled does not mean that it is itself a profile, right? And if you look at UMA, so many things are so loose (claims gathering, anyone?) that it's way more open than OAuth in terms of decisions. I think "application protocol" or "framework" are appropriate here. I'm particularly sensitive to the language choice here because I once had to untangle a client who was convinced that UMA had fewer choices to make at runtime than OAuth, and as we all know that's simply not even remotely the case. This stemmed from UMA 1.x calling itself a "profile" of OAuth and the client in question interpreting that in the common fashion of "conformant subset". Once we showed them all of the ways that UMA inherits OAuth's flexibility and then adds its own on top, they realized that they had the wrong picture of the world. If we can keep people from coming up with that incorrect picture in the first place, I think it's our responsibility to do so. -- Justin On 12/1/2016 2:29 PM, Mike Schwartz wrote: > > Regarding today's discussion of "framework" versus "profile": > > The SAML profiles document states: "This document specifies profiles > that define the use of SAML assertions and request-response messages > in communications protocols and frameworks, as well as profiles that > define SAML attribute value syntax > and naming conventions." In the SAML sense, a profile is used to > "implement a scenario". For example, the XACML SAML profile > "facilitates this mapping by standardizing naming, value syntax, and > additional attribute metadata." > > Section 1 of OpenID Connect Core Spec: "Notably, without profiling > OAuth 2.0, it is incapable of providing information about the > authentication of an End-User" > > Of course OpenID Connect is also a superset of OAuth 2.0. There are > +/- 50 IANA registrations for OpenID COnnect: > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml > Plus, OpenID Connect defines the id_token and Hybrid Flow, which are > obviously not specified in OAuth 2.0. Can OpenID Connect be futher > profiled... of course. But certainly it provides a mapping of OAuth > 2.0 to implement a specific use case--a sign-in flow. Many times I've > heard of OpenID Connect being referred to as a profile by other > authors of the spec. > > So the idea that a profile is a "subset" of functionality is absurd. A > profile makes something more specific by elaborating on the details. > And the profile itself may still be generic--hence our aversion to > racial profiling. > > The fact is, OAuth 2.0 is a generic framework that provides a common > denominator that is useful for many applications. Clearly UMA has a > specific application in mind, tries to align with OAuth 2.0, and thus > IS a profile. The fact that it can be futher profiled does mean that > it cannot itself be a profile. > > - Mike > > > > > > ------------------------------------- > Michael Schwartz > Gluu > Founder / CEO > mike(a)gluu.org > http://support.gluu.org > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma

1 0

Agenda for UMA telecon 2016-12-01
by Eve Maler 30 Nov '16

30 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-11-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10> - Logistics for upcoming meetings (calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>) and 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> check-in - *Dec8/9:* no meetings (consider meeting Wed afternoon or something?) - *Dec 15/16:* meet as usual - *Dec 22:* meet as usual; RSVP – Dec 23: no meeting - *FYI:* End game for V2 specs looks like this: - WG vote to publish Draft Recommendations (consider this an "implementers' draft"?) - 45-day Public Review - If no changes, LC votes to certify Draft Recommendations for All-Member Ballot - Ballot takes 14+ days - If no changes, Recommendations are prepared for publication and published - Total: if no changes, up to 90 days - Work on UMA.next issues – Core is up to 09 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html> and RReg is up to 02 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html> – please review changes ahead of time if possible - Core: token profiling, rhetorical - To discuss specifically: - Set math (see forthcoming email for discussion points) - Remove policy-specific resource/scope description properties from RReg and add as extensions in Core? - AATs could be used for "stateful trust elevation"/step-up authentication; do we have any equivalent now, and if not, is this lack okay? - claim_token_profiles_supported: Provide real profiles for OIDC and maybe SAML? - uma_profiles_supported: What to do with the extensibility profiles? - Need to have IANA registry entries for both old uma-configuration and uma2-configuration? - Shoebox endpoint - Claims hashing - Other issue backlog review/cleanup - See the latest swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #256: Consider the naming of entities and concepts: token/ticket/registration terms
by Eve Maler 30 Nov '16

30 Nov '16

https://github.com/KantaraInitiative/wg-uma/issues/256 This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates a bunch of *token/ticket/registration* terms from the GitHub issue: - requesting party token (RPT) (original) - protection API token (PAT) (original) - authorization API token (AAT) (obsolete) - persisted claim token (PCT) (new) - permission ticket, registering a requested permission (original), registering for a permission ticket (colloquial) - uma_ticket (new; in the URL of the UMA grant type) - register a resource set (original) For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. I'll provide my own thoughts in a followup message. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6

Article on Privacy as a Service referencing Kantara Work
by John Wunderlich 28 Nov '16

28 Nov '16

Behind a paywall, but this article references both UMA and the Consent Receipt. If you have access, give it a read. https://www.computer.org/csdl/mags/co/2016/11/mco2016110049-abs.html Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN> Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Attempt at better clarity around "resources can have multiple parts on the RS side"
by Eve Maler 28 Nov '16

28 Nov '16

I realized that we had an unstated MAY here. Instead of trying to squish the statement into the RReg "protected resource" definition as before, I've now broken this out into a paragraph in RReg Sec 2, Resource Registration, as follows: "A resource server MAY register and manage as a single protected resource a set of digital data or API endpoints that, from its perspective, consists multiple parts, has dynamic elements, or otherwise has internal complexity; it alone is responsible for maintaining any required mappings between this complexity and the resource identifier known to the authorization server." This is something that, in fact, the HEART group has been facing in its discussions about the FHIR API, and other APIs that are working on UMA protection will face it as well (though FHIR has the worst of it since it's a complex API). Let me know what you think. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Reminder: UMA APAC sync coming up
by Eve Maler 28 Nov '16

28 Nov '16

*Purpose:* Synchronizing on current work with APAC-based participants and gathering their input. *RSVPs* from those in the APAC region (sent directly to me) will be much appreciated! *Call may be canceled if no RSVPs* - Sample times: US Pacific *Tue Nov 29* 4pm / Aus east *Wed Nov 30* 11am / NZ *Wed Nov 30* 1pm - Skype: +99051000000481 - US toll: +1-805-309-2350 - Sydney: +61.2.8014.4647 - Auckland: +64.9.973.0310 - Additional international numbers: https://www.turbobridge.com/in ternational.html <https://www.google.com/url?q=https%3A%2F%2Fwww.turbobridge.com%2Finternatio…> - Web: https://panel.turbobridge.com/webcall/ <https://www.google.com/url?q=https%3A%2F%2Fpanel.turbobridge.com%2Fwebcall%…> - Code: 178-2540# - Screenshare: http://join.me/findthomas <https://www.google.com/url?q=http%3A%2F%2Fjoin.me%2Ffindthomas&sa=D&ust=147…> (DO NOT USE join.me <https://www.google.com/url?q=http%3A%2F%2Fjoin.me&sa=D&ust=1475556106312000…> dial-in number) - See the calendar entry for more details: http://kantarainitiative.org/c onfluence/display/uma/Calendar *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New drafts are ready
by Eve Maler 28 Nov '16

28 Nov '16

Core rev 09: https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html RReg rev 02: https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html I closed issues #235 and #236 from Sarah on RReg. We haven't been very disciplined about closing issues that have been implemented and thoroughly discussed in Core, but there's really quite a lot of them that could be closed by now; I'll plan to do that shortly. Biggest changes this time around/food for thought for our call this Thursday: - Token profiling in Core - Lots of rhetorical/conceptual changes in the front part of Core (please read through -- new ASCII art!) - Scope set math is fully on the docket! - Assumption: Only one grant is in use at a time - Assumption: Client-requested scopes are intended to apply only to the apparent resource that the client attempted to access (since they can't know about resource IDs) ?? - Question: What should guide RS's in requesting permissions on behalf of a client? I for one would be very willing to have this week's call go a little long as I have to miss the following week again, and time is getting very short. If anyone can stay long with me, that would be great. Lots still to do. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: No WG or Legal call this week due to US Thanksgiving
by Eve Maler 22 Nov '16

22 Nov '16

I do plan to have Core 09 and RReg 02 out sometime after Thursday, though! The Core changes will concentrate on the Intros, conceptual descriptions, and new diagrams (so text diffs will unfortunately be a bit invasive). Happy Thanksgiving to all those celebrating it! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Removing RReg's dependency on resource owners
by Eve Maler 20 Nov '16

20 Nov '16

Currently in RReg we make the "name" property in the resource description and the scope description REQUIRED, for the UMA use case. Given our discussion in the 2016-11-18 telecon about softening resource owner-related things in RReg, properly these should be OPTIONAL (since OAuth and OIDC don't involve "setting policies", and OAuth sometimes doesn't involve resource owners at all, only clients acting on their own behalf). Should the Core spec profile RReg to make these properties REQUIRED vs. OPTIONAL? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0