SIOP and Entity Resolving Identifiers

[David Waite]

I propose a simplification of SIOP and DID usage, where client_id and issuer are “entity resolving identifiers”, and subject is when it is a URI.

An “entity resolving identifier” uses a trusted process, to authoritatively resolve OpenID Federation entity statements into leaf entity metadata for an entity based on a given URI and scheme.

This definition is purposely meant to overlap DID resolution and the HTTPS-based resolution in the OpenID Federation drafts. It allows for DID resolution (and other potential future schemes) to be defined as an independent process.

If this resolution process is defined as an API, one would expect it to look similar to:

func requestEntityMetadata(
  client_or_issuer: URI,
  authority_hints: Array<URI>) -> (leaf_entity_metadata: JSON, jwks: JSON)

Specifically:

1. Data is returned in the combined metadata format of an entity statement, and not just as OpenID Server Metadata. This is meant to allow for consistent rules for both RP and OP roles, and to allow for future expansion of roles.
2. The entity statement is JSON and not a JWT, in anticipation of some resolution schemes providing a different integrity protection mechanism than signed/encrypted JWTs.
3. The Federation resolution logic, e.g. chaining to an authority and combining metadata by policy, is encapsulated by the API. Note that this could conceivably be cross-scheme, e.g. a DID-identified client having a HTTPS-based authority.
4. The JWKS is given as JSON data. OIDC Federation also allows the JWKS to be signed by the entity statement key. The process for resolving the key set may also come from an alternative resolution scheme and content format, such as verification methods on a DID document. For SIOP, #1291 may mean that there is no JWKS information provided here.
5. Because data is not given in a way where authority and integrity can be independently confirmed, this is necessarily a trusted process/component.

The metadata for an RP or OP would be expected to include information on resolvable identifier schemes supported. The resolution schemes SHOULD have a prefix of the URI method, but may have further distinguishing data (such as a DID method, as these each require different resolution implementations).

[Kristina Yasuda]

Regarding 1, DID Document would be expected to include a full “entity statement”? I am not sure it can be mapped to any of the already defined components in section 5 of DID-CORE - it kind of maps across verification methods and verification relationships.

[David Waite]

The core concept of the proposal is to define a separation between resolution of metadata and processing based on that metadata, such that DIDs would be a drop-in on existing OpenID Connect Federation logic (and thus onto the rest of the core specs). It also means defining such a resolution spec could be done by people with significantly less OIDC knowledge, possibly allowing more DID subject matter experts to contribute/review.

It also doesn’t constrain the new effort to just the support of DIDs.

Similar to the interface of a DID resolver API, it does not attempt to preserve verification of the data instead opting for a trusted (sub)system. This gives significantly more freedom to additional steps and transforms in resolving authoritative entity statements - even if the data comes from multiple sources, are a subset of a larger body of resolved metadata, are in another format like RDF or XML, etc. The definition for DID-based resolution would include those details. Ideally, it would be defined in such a way to preserve the extensibility of entity statements themselves.

This is also why the example API gives a fully combined entity statement as a result. This gives a resolver scheme the ability to define authority statements in another manner than the HTTPS-based Federation API defined in OpenID Connect Federation.

[David Waite]

See also: #1263, #1272, #1259, #1198, #1241

[Kristina Yasuda]

For DIDs, including entire Registration Metadata (ie Entity Statement) inside a DID Doc would not be recommended because 1/ size of a DID Doc matters as DID Docs need to be replicated by nodes across the system and 2/ there is no dedicated top-level property in DID-CORE for that purpose.

The way to go seems to be hosting Entity Statement at an endpoint and including that endpoint as a serviceEndpoint property in DID Doc as specified here https://w3c.github.io/did-core/#services

‌

[Torsten Lodderstedt]

Is there a PR available for this proposal? That would be helpful to fully understand the proposal and its consequences.

Note: is the proposal specific to SIOP? I would assume it could be used in traditional OIDC as well (and is already the case for federation).

[David Waite]

A PR is incoming, and there’s a diagram at https://hackmd.io/arF-7bL1SCSLsR2hKMdIlQ

There are two aspects:

1. Defining an interface for resolving metadata from a URI. OpenID Federation becomes one obvious method for doing this, but the feature needs to be a bit more abstract than federation to give other URI schemes like DIDs more flexibility.
2. Defining metadata to describe accepted resolution methods for RP metadata on an issuer.

There’s an open issue whether these schemes can be defined to be unique per URI, or if we can potentially have multiple supported resolution mechanisms for a single URI (and if that creates any downgrade considerations or need to express which mechanism is in effect during request/response).

As far as usage beyond SIOP, it is certainly feasible - one approach would be to pitch whether enough of this could be added to Federation proper, at which point it could be leveraged by SIOP.

[Tom Jones]

The question needs to be formulated in terms of what information does an RP (aka client) need to acquire before granting access to some resource - authz is the end goal of authn in most cases. So the siop needs to make some sort of assertion (or attestation for high levels) about a collection of attributes. (These can be in an entity statment or VP or whatever is selected) What is needed is a format definition of that statement, which is, i believe, what DW is requesting here. I agree with that. Here are some of the statements:

1. static statement about the siop software. See the Kantara MAAS spec https://docs.kantarainitiative.org/Kantara Mobile Assurance Statement 1_0_0 draft v2 FIRE final Oct 27^LJ 20.html
2. Instance statement about the siop installed instance - still static but could have a nonce to prevent replay.
3. Dynamic statement from the siop installed instance - includes liveness tests on the user.
4. Full attestation of the software - this is the hammer that John keeps beating. - a yubi key can help but in the end we need to bite the bullet and do a full attestation service - that will only apply to LOA 7

So here is a taxonomy of some of the methods that might need to be included in a liveness instance response. https://tcwiki.azurewebsites.net/index.php?title=Proof_of_Presence#Taxaonomy

[David Waite]

@Tom the issuer here (and metadata resolved from it) is meant to provide a policy and featureset for a class of SIOP instances (representing different End-Users and potentially written by different manufacturers) to operate under.

The motivation is to have a single issuer value represent a group of compatible SIOP instances, as a web site or native app is otherwise sandboxed from getting a list of available (aka installed) SIOP implementation issuer values.

For attestation purposes, is likely that merely having the issuer represent SIOP instances of a single manufacturer will be insufficient. This is because some platforms such as Android 12 will still not enforce this behavior and will allow side-loaded and user-approved apps to replace web content (e.g. take over app links).

Instead, I’ve imagined that it will be more an attestation of the software (such as via Android SafetyNet or Apple DeviceCheck statements) represented as a credential which may also be requested by the verifier.

So far, I’ve not been focused on the requirements for this. I was hoping this might come from the DIF Wallet Security group, but this group appears to have stalled.

[Tom Jones]

Yes, i went to the first few DIF wallet meeting, but they couldn’t agree on a set of achievable goals, so i left. The MAAS link above is meant to provide the app certificate that can be requested by the verifier. It was designed to solve a problem in US Healthcare and has been formally proposed to ONC. Not sure what will come of that, but i would appreciate any feedback of the suitability of the MAAS doc spec for that purpose. Note that information hiding is inappropriate for such a doc, so the VC format is not helpful in any way.

[Tom Jones]

I should add - the federation trust authority is only a helper function for the RP. It is the RP needs that must be met. It is likely that one RP will be a member for more than one federation as so the nascar problem is not elimited, but hopefully reduced to a manageable number of logos on the RP page. Given the current turmoil in the W3C effort about where a did method can be known to be secure, i can certainly imagine one trust authority would include all of the did methods that were provably secure. Another one might be for all green (energy-efficient) did methods.

[David W Chadwick]

In my opinion the trust model for SIOP with VPs is that no software on the end user’s device can be trusted. The RP’s trust is in the issuers of the VPs, and they will publish their own metadata that the RP can download. So the RP needs to know:

1. That the issued VCs have not been tampered with since the trusted issuers issued them i.e. the user’s attributes are verifiable (and the signed VCs provide this)
2. That these VCs belong to the device user who is asserting them i.e. the user has not picked up somebody else’s VCs and is asserting that they belongs to him/her. (the use of keys that are stored in the device’s hardware, and that identify the user/subject in the VCs, and are used to sign the VPs provides this. But only for holder=subject. For holder NE subject then another mechanism is needed)

‌

[Tom Jones]

When i read your introduction i thought you had made the problems much simpler. But then i found two statements which cannot both be true in any rational universe.

1. That these VCs belong to the device user who is asserting them i.e. the user has not picked up somebody else’s VCs and is asserting that they belongs to him/her. (the use of keys that are stored in the device’s hardware, and that identify the user/subject in the VCs, and are used to sign the VPs provides this.
2. the trust model for SIOP with VPs is that no software on the end user’s device can be trusted. The RP’s trust is in the issuers of the VPs, and they will publish their own 

If the second is true there is no purpose in having keys on the user device as it is not trusted.

[David W Chadwick]

Tom you are correct. We are currently addressing this trust deficit by implementing direct anonymous attestation of the device, then the RP will trust the DAA issuer, and VCs issued to devices that are attested to. But until DAA is implemented our current trust model is that we only trust the OS and the hardware, and we don't trust any installed software apps. We believe that if a device is stolen and the thief tries to access it then the OS will delete the keys in the hardware and so no VCs can be stolen.

[Jeremie Miller]

I think there is an in-between trust model also: the RP trusts that the Issuer has done device validation before it generated/delivered the VC (which may be via DAA, MDM, or some other mechanism only available to the Issuer).

[David W Chadwick]

But if its a long lived VC (as most people are using) then what if the device is compromised after the VC was installed in the wallet? Issuing short lived VCs would work because the window for attack is considerably shortened. Otherwise with long lived VCs the holder would have to go back to the Issuer of the long lived VC each time before it is presented to get a clean bill of health (similar to PKC Stapling).

[Jeremie Miller]

I agree the risk is higher for a long-lived VC and that should be factored in, but I would argue that it is still a valid trust model for the RP to expect the issuer to determine the appropriate lifecycle timing for the VC when it is issued (i.e. have an appropriate exp).

[David Waite]

As stated elsewhere, I do not believe the concept of “no software on the end user’s device can be trusted” is tenable, and needs to be substituted by an attacker model.

In particular, “direct anonymous attestation of the device” is useless if your model is that the device can never be trusted for any purpose. This concept means also that it is impossible to create a SIOP implementation that represent’s the end-users interest in terms of consent and release, as the device may be sabotaging such efforts.

As stated it sounds like a much stronger model than say FIDO 2, where the client (aka browser/device the user is interacting with the relying party through) is a trusted system and currently has no opportunity for attestation to either the relying party or authenticators.

[David Waite]

We have built a limited form of this for SIOP by supporting OpenId Federation, and supporting DIDs with the registration parameters.

In the future, it may be desirable to build a separate specification from SIOP usable for just-in-time registration of OAuth clients.