Is `i_am_siop` sufficient to distinguish SIOP and non-SIOP ID tokens?

[Daniel Fett]

There might be attacks where an RP expects to be speaking to a non-SIOP, but the RP is in fact talking to a SIOP.

Until now, this was prevented by the special iss value.

Now, the RP might not notice the self-issued nature of the OP, at least under some circumstances, e.g., when discovery or the check of the ID token signature is not done properly.

The i_am_siop Claim is not sufficient, as it expects any RP to actively check for its presence.

A better mechanism would be something that invalidates the ID token for any RP that does not intend to speak SIOP.

The issuers identifier would be a good candidate: We could either rename it for SIOP:

{
   "siop+iss": "https://dynamic.siop.example"
   ...
}

… but that is probably a big change and we have to answer the question what happens when both “siop+iss” and “iss” are present.

Another option would be to prefix the issuer:

{
   "iss": "siop+https://dynamic.siop.example"
   ...
}

This feels a bit closer to what we want to achieve - tell the RP that this ID token is to be handled with caution.

In both cases, a non-SIOP RP that performs the most basic checks on the ID token will reject it.

[Thomas Bellebaum]

Messing with the Scheme could be problematic later on, if someone ever wants to resolve the URL for any purpose. How about using the authority:

{
   "iss": "https://[e-mail]"
   ...
}

‌

[Thomas Bellebaum]

A bit Off-Topic: We could use a word for non-SIOP OPs. Unless such a word exists, I suggest TOP for Trusted OP, because of the necessary trust relationship between TOPs and RPs

[Kristina Yasuda]

Would the RP that was expecting non-SIOP, but ended up talking to SIOP be able to resolve a JWK thumbprint + sub_jwk OR a DID in sub?

If yes, does RP need to distinguish SIOP with dynamic OP discovery from a non-SIOP?

If no, RP should reject the SIOP ID Token because it was expecting to talk to non-SIOP and cannot handle certain SIOP elements. (in which case do we really need i-am-siop…)

[Daniel Fett]

@Thomas Bellebaum The fact that the scheme is unresolvable is intentional - the URL should not be resolved if SIOP is not understood by the RP.

@Kristina Yasuda A non-SIOP-expecting RP would not try to resolve the sub, but just process it as a string.

[Thomas Bellebaum]

@Daniel Fett Fair point, but we should achieve this without defining our own schemes (or entire siop+ prefixes for arbitrary schemes). We should restrict the set of possible values, not extend it.

For example, we may require SIOP URIs to include a siop keyword at the beginning of the authority (siop.example.org) and then specify that such URLs must be unresolvable. Or we could reuse self-issued.me and define a subtree of domains rooted below it for SIOPs to use. Then the OIDF could enforce unresolvability itself.

[Stephane Durand]

I am struggling to see how a RP expecting to interact with a non-SIOP could get a SIOP response. (The other way around seems easier, though), Do you have an attack scenario in mind?

Then I also wonder whether it’s OK for a RP to carry expectation towards the SI- nature of the OP (and subsequently fail to see met realize). I would imagine that proper verification should consider:

• The validity of the id token itself
• Whether the RP trusts the OP, which should be resolved on the iss field and possibly other contextual information (TLS certificate, reputation, attestation of relevant qualities).

I am not questioning the solution, which I find nice (and I understand that “siop+http” in Daniel’s proposition is not intended to be taken as a scheme, but really as a broken something when considered as a non-SIOP token, and in the case of SIOP it’s defining the iss value as 'siop+' || https url ), but rather if there is a real problem in the first place.

‌

I understood ‘i_am_siop’ as a way to enable a generic implementation of id token verification wherever they come from. It is not essential, but could help decouple the two steps mentioned above.

[Thomas Bellebaum]

Whether the RP trusts the OP

I still believe SIOPs are untrustworthy by design, as they are meant to be run under a user’s control and thus represent his will, and his will only. That was the main distinction between non-SIOPs and SIOPs in OIDC Core, and I have not yet seen good arguments against it in this draft.

[Tom Jones]

Very few of the siop implementations will actually be under the user’s control. That has been a conceit of the ssi community that is really beyond the capability of 90% of the human populations. I think it is time that we addressed reality instead of fantasy. I suspect that the interesting RPs will require communications with a variety of user wallets to acquire sufficient user information to allow issuance of an access token which will be a combination of the various credentials residing in their respective “wallets”. This is the only way that eID or mDL creds can be accommodated. Really SIOP is just a scope value. It is the presentation of the cred that will need to be trustworthy.

BTW - nothing i said mitigates the need for zero trust of any communications from the user. That fact should go without saying.

[Thomas Bellebaum]

Very few of the siop implementations will actually be under the user’s control.

• Malicious users do not ask for control
• Honest users do not require Auth in the first place

I suspect that the interesting RPs will require communications with a variety of user wallets to acquire sufficient user information to allow issuance of an access token which will be a combination of the various credentials residing in their respective “wallets”.

Having (say) an App for every piece of information will severely hinder adoption. Just like most people I know are not always willing to install yet another messenger app for communicating with new people or installing a new app just to buy a ticket for public transport, most people do not want to install an app every time they are required to store new data on their phone. More concretely:

I suspect that the interesting RPs will require a combination of the various credentials
residing in the user's “wallet”.

It is the presentation of the cred that will need to be trustworthy.

Correct. This is exactly the point of SIOPs. To present claims which are not to be trusted unless issued via a trusted third party infrastructure.

[Stephane Durand]

I still believe SIOPs are untrustworthy by design

SIOP (like connect), is just the protocol, so it can only “maintain the trust” through communication at best. The trust is rooted in other aspect of the (SI-) OP. As a matter of fact, I do have my own doubts as to whether SIOP can really “maintain trust” in all cases (there seems to be a consensus around cross device shortcomings at least).

My point above was that it’s for each RP to come up with their own definition of trust (which you or I may disagree with, but that’s its own responsibility). For that, the RP could consider the reputation of the OP (“easy” with non SIOP, not possible with SIOP), or other types of evidences the OP could provide.

For example, a RP could trust a SIOP because the SIOP has (somehow) shared an attestation that it has received and protected credentials in line with certain (security) standards. Then, the RP could consider that the SIOP’s trustworthiness is for example as good as the issuer of the credentials.

[Tom Jones]

RPs are interested in authz, authn is just one step in granting authz. RP’s will collect data so long as:

1. users are willing to share their private data
2. rps are missing data they require to authz

‌

[Tom Jones]

siop is NOT a protocol, it is an entity

[Thomas Bellebaum]

@Stephane Durand We agree on this, I think I was a bit vague there.

[Tom Jones]

in the case of state issued id, there is no meaningful difference between the online (browser) case and the off-line (SIOP) case. Same issuer, same values, same trust.

[David Waite]

There are three protections:

1. SIOP implementations issuers sign tokens that represent the subject authentication directly, rather than indirectly through the issuer. If you do misunderstand whether it is a SIOP or OP, you will be comparing the signature against the wrong key and fail
2. SIOP metadata should not have jwks uri, thus cannot be issuer signed and ROs which do not understand SIOPv2 will fail to understand the metadata
3. i_am_siop flag indicated the metadata is SIOP metadata explicitly, so a transient issue in resolving JWKS does not result in an RP interpreting the OP metadata being SIOP metadata as a transient failure

I would not be in favor of a modification flag of the uri, as we do not have a uniform way of making such modifications. I also don’t think it is necessary

‌

[Tom Jones]

IMHO the following statement is just flat wrong

“SIOP metadata should not have jwks uri, thus cannot be issuer signed “

If fact all the did stuff is SIOP signed., so why not metadata. What’s the dif?

[Kristina Yasuda]

on 2021-11-25 SIOP call, we discussed that RP expecting response from a non-SIOP will not be able to validate the ID Token even without an explicit i-am-siop claim because it will treat sub as a string but will not locally find an identifier matching to it.

the question becomes whether this is enough to prevent confusing existing RP implementations when they unexpectedly receive SIOP ID token. we agreed to think about concrete attack scenarios to answer this question.

We discussed that for new SIOP oriented RPs, i-am-siop claim would be enough.

[Daniel Fett]

I agree that we can close this for now.

[Kristina Yasuda]

resolved at 2021-12-02 SIOP call per Daniel F. recommendation