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

Marius Scurtescu mscurtescu at google.com
Mon Feb 26 20:16:00 UTC 2018


On Mon, Feb 26, 2018 at 12:12 PM, Phil Hunt via Openid-specs-risc <
openid-specs-risc at lists.openid.net> wrote:

> If oauth is assumed required than implicit cases are  excluded since they
> do not have oauth in a significant number of cases.
>

Implicit cases are not excluded, it is only assumed that they will use
OAuth 2 for authorization. Not saying it has to be like that, just that
there is no exclusion.


>
> If the intent is to require oauth then we need to agree on that because it
> excludes participants.
>

Yes, we definitely need to agree.



>
> Phil
>
> On Feb 26, 2018, at 12:04 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> Implicit use cases would happen in SAML as well, would they not? The
> implicit use case would be an OIDC flow, not OAuth. There is shared user
> identifier in OAuth.
>
>
>
> I’m confused by this statement. This RISC charter states:
>
>
>
> Internet accounts that use email addresses or phone numbers as the primary
> identifier for the account will be the initial focus.
>
>
>
> What change in direction are you referring to?
>
>
>
> On 2/26/18, 11:55 AM, someone claiming to be "Phil Hunt" <
> phil.hunt at oracle.com> wrote:
>
>
>
>
>
> 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.
>
>
>
> Phil
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Drisc_Week-2Dof-2DMon-2D20180205_000439.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=wj-hfBcSv3M7ndsxoK-cxJssgaJmDC7EagzTvgba_hc&s=Vd9UeCxGq9hZliDVJpZzz1m0VvKzPiquCradIos5QX0&e=>
>
> 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:
>
>
>
> 1)      Add/remove subjects when the subject is not added implicitly
>
> 2)      Check operational status of the event stream
>
>
>
> (1)    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.
>
> (2)    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
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180226/e7322624/attachment-0001.html>


More information about the Openid-specs-risc mailing list