[Openid-specs-risc] RISC Profile

[Marius Scurtescu]

On Mon, Feb 5, 2018 at 11:29 AM, Phil Hunt <phil.hunt at oracle.com> wrote:

> Marius,
>
> Thanks for the draft.
>
> Some questions:
>
> Section 2 - Subject Identifier.
>
> How is the JSON object conveyed in SET?  Is it in the payload identified
> as an attribute?  Is it the value of “sub” in the top level?
>

Good point. It is meant as event payload, the event types spec has
examples. This should be made explicit and an example should be provided in
the RISC profile.



>
> Section 3 - Discovery
>
> There is a lot of metadata that to me is not service provider wide - but
> is stream specific. Example, signer certificates may be assigned in
> pairwise or domain specific fashion.  This may be of particular concern to
> tenancy based service providers.
>

Key resolution is very similar to OIDC, it is based on issuer, hence not
stream specific. Not saying it cannot be, just that this is the approach.
Other profiles can choose different ways.


> Included in the discovery should be some discussion of authentication and
> authorization.
>

Do you have a concrete suggestion? The RISC profile addresses authn and
there was no need for anything in the discovery doc.



>
> Should discovery not be part of SECEVENTs?
>

Could be. Several parts of this profile could theoretically be moved to
secevent. First I think it makes sense to see a complete and consistent
solution and then if the secevent working group shows interest we can look
at splitting parts out.



>
> Note also, an issue came up in OAuth Metadata and Connect well-known paths
> - Mike can probably explain. See:
> https://www.ietf.org/mail-archive/web/oauth/current/msg17745.html
>

Interesting. Do you have a concrete suggestion how discovery could work?

For example, for:
GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1
Host: example.com

The actual issuer URL is: https://example.com/issuer1/

Is the issuer URL the same for:
GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com
?

If yes, is this how discovery should work:
{host of issuer} + "/.well-known/risc-configuration" + {path of issuer}
?



> Section 4 - we had discussions in Singapore that a majority of attendees
> indicated they need a multi-profile management API.  Why does the RISC
> document have one?
>

We went back and forth on this quite a bit. The current management API
proposes only one stream between one transmitter and one receiver. Allowing
multiple relieve some receivers of the need to implement a dispatcher. We
can definitely pick up that discussion.


>
> I understand there is some pressure for the pilot, but it would seem to me
> that the pilot can be done through manual administration and should not
> require a management API (except for error checking) at this time.
>

The pressure is to have a concrete implementation ready proposal so we can
have a discussion in the concrete and to see all details. The pilot is not
the pressure (and as you mention, not really needed for a pilot).


Thanks for the feedback,
Marius


> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com
> phil.hunt at oracle.com
>
> On Feb 2, 2018, at 2:25 PM, Marius Scurtescu via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
> <risc-secevent.pdf>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180205/bda3801a/attachment-0001.html>