[Openid-specs-ab] SIOP v2 Review

[David Waite]

Adding my responses as well

> On Nov 8, 2021, at 5:18 AM, Kristina Yasuda via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> From: Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>>
>snip
> Here is my detailed feedback: 
> 
> - "Relying Parties typically cannot pre-establish registration with a Self-Issued OP, as each End-user might be represented by a different, locally-controlled Self-Issued OP instance. This specification extends the authentication request with a mechanism with additional dynamic registration techniques for feature negotiation.“
> 
> Other models are possible, e.g. all instances of a wallet app sharing the same RP registration data. This should be mentioned in the spec. 
> -> below text added in this scope section. Still need to think how to add this to other sections such as the registration metadata section.
> "In another model, when all instances of Sel-Issued OPs share the same RP registration data, it is possible for the RPs to pre-establish registration with that set of Self-Issued OPs."
> Assuming that the method used by the RP in this case would be out-of-band or Dynamic Client Registration..?

I consider there several variants of relationships between the RP and OP; either you have a pre-existing/out-of-band relationship or a dynamically established relationship based on resolved OP metadata and one of:

1. dynamic client registration
2. resolved RP metadata
3. resolved RP keys, with non-credential RP metadata via a “registration” parameter in a signed request
4. client_id = redirect_uri with spec-synthesized RP metadata, or spec-whitelisted values in a non-signed “registration” parameter"

There’s not really a reason any of these are exclusive to OP or SIOP support, but there are compromises - for instance, DCR would require a hosted shared component for SIOP use.

I somewhat hope that since publishing a native app requires you to have a web presence per App Store rules (and an interactive web app will as well), we can eliminate #4 and possibly #3.

>snip

> - "## Relying Party Registration“
> 
> The new revision supports entity statements and DIDs as only client id. This mandates signed requests for SIOP, which makes SIOP significantly more complex to implement. How is this justified?
> 
> I personally would feel better to retain the simple "client id is redirect uri“ approach as third option. 
> -> The intention was not to remove "client id is redirect uri“ option. I added the text clarifying that when the request is not signed, "client id is redirect uri“.
> -> I also added a summary of the options in the very beginning of the registration and discovery section.

First, if automatic client registration requires a signed request, we need to figure out why that requirement is there and potentially push to remove it. To my eyes against the current spec, the trade-offs between signed and unsigned requests are identical with or without federation - so mandating signed requests should be a policy the authority root sets, not the spec.

Separately, I’m fine if the client_id = redirect_uri allows no registration metadata override, or if someone goes through the effort of defining a whitelist of which registration metadata parameters are usable within an appropriate attacker model. Limiting the attacker model would be key there - there are plenty of metadata values like ‘client_name’ and ‘logo_uri’ which I would not display even from entity statements, but that is a reputitional impersonation and not a protocol-level one.

We will however need to differentiate now whether the client_id is meant to be synthetic metadata (based on the value being a redirect URI) or hosted metadata (resolve via .well-known or some other mechanism) for https schemes - we will have two uses within the same namespace.

For that reason, I _hope_ we don’t need client_id = request_uri going forward, because the interplay with other client_id values and the registration data attacker model aspects make it messy, and I really don’t want to risk the same client_id being interpreted as an entity statement or a redirect_uri based on some transient web hosting issue - especially if that grants an opportunistic attacker to be able to specify their own registration data inline.

> - "# Self-Issued OpenID Provider Response {#siop-authentication-response}" does not describe handling of SIOP responses with other than "https://self-issued.me/v2 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fself-issued.me%2Fv2&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ce8687928bf7848967c2c08d9a1e912f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637718844724683333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=l1sGYdWOSvIDqjHKCJDSUJcai47TQ%2FVTAKL9hCXvVeE%3D&reserved=0>" iss values

I believe this is an ongoing point for discussion - whether responses are differentiated by issuer metadata or if the id_tokens themselves are stamped in some way to distinguish them from non-SIOP id_tokens.

I feel we can do better than having “iss” being the stamp on id_tokens to show them as being self-issued, especially since it does not buy us anything with regards to compatibilty - even a OIDC core implementation which used the old self-issued URL as the issuer to differentiate will not recognize the new self-issued URL.

>snip
> - "1. The RP MUST validate the signature of the ID Token. When Subject Syntax Type is `jkt`, …" 
> 
> It ist unclear to me how the RP determines what subject syntax type is used. Is it the existence of the „sub_jwk“ claim in the id token? 
> -> Currently, if subject syntax type is did, sub=did:<method name>:<identifier>; if subject syntax type is jwk, sub_jwk is present. I added a text to this meaning, but feedback welcome if this is enough and makes sense.

A previous proposal which I think is still worth proposing is whether we are willing to make a clean break with sub_jwk, and instead define a JWK URI scheme.

Then the SIOP limitation becomes that the subject must be a URI and that the URI can be resolved to a key or set of keys. The processing logic gets cut significantly as abstractly the step is working the same way. Syntax types are defined exclusively as a registration negotiation item.

This also means that a client-id could be a JWK URI, which makes it relatively simple for clients willing to do signed requests to embed their effective registration metadata with zero hosted metadata.

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20211109/5367e105/attachment.html>