[Openid-specs-risc] [Cancelled] RISC Weekly 2/21

Phil Hunt phil.hunt at oracle.com
Mon Feb 26 19:55:17 UTC 2018

My understanding was that implicit use cases exist because no oauth relationship exists. RISC is doing subject management because in the absence of oauth there is no explicit oauth consent. 

This exclusionary change in direction needs discussion and a consensus call. 


> On Feb 26, 2018, at 11:32 AM, Hardt, Dick <dick at amazon.com> wrote:
> My feeling is that any RISC Profile should only deal in issues or opportunities unique to RISC.
> I agree. If an aspect is clearly specified somewhere else, and meets RISC’s requirements, we should use it.
> It has not been clear what those RISC specific scoping issue are. Hence, I do not see the purpose for the current RISC Profile draft. For my part, I was expecting a draft that actually defined RISC Events.
> Dick commented on Feb 5 that:
> http://lists.openid.net/pipermail/openid-specs-risc/Week-of-Mon-20180205/000439.html
> I think “need” is too strong. A single management API is desired.
> Another aspect is that the management requirements of RISC, SCIM, OIDC etc. so far look quite different.
> RISC has specific needs, and with a concrete API, there can more easily be a discussion on commonalities, or lack thereof with other SecEvent profiles.
> These statements don’t really play out. The RISC group has not really identified why RISC is unique. 
> Let me clarify then. As I see it, RISC has the following control plane requirements:
> Add/remove subjects when the subject is not added implicitly
> Check operational status of the event stream
> Is not required by either OIDC or SCIM as subjects are determined implicitly by the protocol. Using SCIM for subject management in RISC has been deemed heavy for everyone except those already using SCIM. There currently is no WG document in SecEvents for subject management.
> Is unique to SCIM. There currently is no WG document in SecEvents for subject management.
> If SecEvents WG sees (1) and/or (2) to have common usage across SecEvents, and the SecEvents WG adopted a WG document for them, then it would make sense to not do that work in RISC, but that is not the current state, and given the contention in SecEvents, I think it is important for the RISC WG to move forward and create specifications that meet its requirements.
> I agree that RISC should be agnostic on what protocol is being used for how 2 parties have a mutual subject, be that OIDC, SAML, shared email, or shared phone number.
> /Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180226/fa0da50c/attachment.html>

More information about the Openid-specs-risc mailing list