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

Hardt, Dick dick at amazon.com
Mon Feb 26 21:24:41 UTC 2018

On 2/26/18, 12:59 PM, someone claiming to be "Phil Hunt" <phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>> wrote:

Both protocols (data and control plane) have the same issue depending on which entity is processing the http requests.  If using http push plus control plane, RISC is using bi-directional communications between partners with differing/asymmetrical http security infrastructure.

Marius’ proposal for the data plane was that the receiver set the WWW-Authenticate header that the transmitter sends.
RISC is not bi-directional, it is unidirectional so far. There is a transmitter and a receiver.

An email provider may have no oauth. Adoption of oauth extensions for imap is still relatively non-existant.

Not sure why that is relevant. OAuth for IMAP would be at the data plane.

Not all web sites support oauth. Even oidc clients do not necessarily have oauth infrastructure other than JWT validation.

Once again, OIDC is irrelevant, but an OIDC client will have client credentials to perform 2 legged OAuth to acquire an access token to make control plane APIs to the RISC Transmitter.

There are many “legacy” identity silo sites (that act in implicit federation mode) that are using security access monitors (CASB) to manage user and session security. These have no explicit oauth capability.

We are talking about two legged OAuth for control plane. It is a pretty simple flow of using credentials to acquire an access token. What we are specifying is that control plane authentication is having providing a bearer token.

If RISC is going to require oauth on both sides, a clarifying charter change is needed to narrow the scope of implicit support.

RISC is unidirectional. Unclear what this has to do with implicit still.

I don’t feel it is reasonable to exclude non-oauth IDPs and RP sites from the overall security picture. In particular, there is a significant CASB market out there that would like to participate in the identity risk ecosystem.

The protocol the IDP / RP can be independent of the control plane. What is blocking a CASB from participating? How the access token is exchanged is out of scope. By deciding that the control plane APIs use an OAuth token simplifies implementations as they know they get an access token, as opposed to basic auth, or mutual TLS, or whatever other HTTP authentication. Are you suggesting we NOT standardize control plane authentication?

We discussed this control plane architecture in Singapore wrt SecEvents, so I am confused why this would be controversial for RISC.


On Feb 26, 2018, at 12:17 PM, Hardt, Dick <dick at amazon.com<mailto:dick at amazon.com>> wrote:
Are conflating data plane and control plane?

We have talked a number of times in the WG about requiring OAuth for control plane authorization. We talked about this in the SecEvent WG meeting in Singapore. Note this would be two legged OAuth.

I don’t think there is any requirement that the user used OAuth.


On 2/26/18, 12:13 PM, someone claiming to be "Phil Hunt" <phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>> wrote:

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

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

On Feb 26, 2018, at 12:04 PM, Hardt, Dick <dick at amazon.com<mailto: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<mailto: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.


On Feb 26, 2018, at 11:32 AM, Hardt, Dick <dick at amazon.com<mailto: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:

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180226/816bb3ac/attachment-0001.html>

More information about the Openid-specs-risc mailing list