Credential issuance with unknown (i.e. not pre-registered) wallets

[pmhsfelix]

Is there anything being planned for supporting the issuance of credentials to wallets that don't have a pre-registered OAuth Client on the issuer's AS?

Q1: I presume that in open and low assurance environments, a wallet should not need to be pre-registered on all the issuers an user may use, right?

For OpenID4VP, we have the client_id_scheme concept (https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#client_metadata_management), which allows for alternative ways of dealing with OAuth clients (Verifiers in the VP case), other than pre-registered. However, no similar mechanism is available on VCI.

Q2: Is the use of Dynamic Client Registration (RFC 7591) the only way to deal with wallets that are pre-registered on the issuer's AS?

[paulbastian]

I think that Attestation-based Client Authentication is our intended solutions for this: https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/ However, it might be a little to complex for open/low-assurance wallets

[pmhsfelix]

Even with Attestation-based Client Authentication, the client (not a specific device) needs to be pre-registered, right? I.e. the client_id provided on authorization and token requests must have been previously registered on the AS, alongside things such as the allowed redirect URIs

[paulbastian]

I imagine issuers may rely on trust lists for Wallet providers that contain client_ids. Is that an indirect form of pre-registration?

[pmhsfelix]

That could eventually work, but probably we need a spec to define the content on those interoperable trust lists, namely because we need more than just the client_id (e.g. the allowed redirect URIs). We could eventually use the DCR schema for the content of those lists.

[peppelinux]

@pmhsfelix the approach we have in italy is more a kind of ephemeral automatic client registration where:

• the wallet instance provide its wallet instance attestation in the AS Authz endpoint
• the AS evaluates the trust to the issuer of the wallet instance attestation (wallet provider)
• the AS evaluates the validity of the signature and of the security capabilities of the wallet instance, according to its wallet instance attestation
• the AS creates an ephemeral session for the scopes of the authorizations

this means to us that there's no need of persistency of client registrations, since the wallet instance attestation is ephemeral and short-lived. The VCI may store the WIA verified at the time of the issuance.

The trusted list in italy is distributed and implemented using OpenID Federation. The Wallet Instance Attestation should contain the issuer's trust chain (to be fastly updated using the source_endpoint withing its statement) or not, in this case a federation entity discovery starts using the sole wallet provider unique identifier (HTTPs URL). the first cases works also for offline use cases.

regarding the client_id ... since it is ephemeral ... In the WIA we have the sub claim anyway. Should we have iss == sub == client_id? Probably this migth be a useless formality. WDYT?

[David-Chadwick]

Trust in the wallet provider is just another symptom of the overall problem of discovering trust in all of the eco-system components. Conceptually there is no difference in determining if an issuer, verifier or wallet provider is trusted. They are all service providers of one type or another in the eco-system, and will all have entries in the trust lists of the trust federation/domain roots of trust that have vetted them. So the solution is essentially the same in all cases. The service provider provides to the relying party: 1) the unique URL of the trust framework that that the service provider is registered in 2) the ID of the root of trust that has registered the service provider, using the naming convention used by the trust framework. 3) its own ID The relying party then sees if it supports the trust framework, and if it does, asks the root of trust if the service provider is listed (and therefore is trustworthy according to the rules of the trust domain). Problem solved (for issuers, verifiers and wallet providers). FYI we have already implemented this for W3C VC Issuers, where the termsOfUse property is used by the issuer to list its supported trust frameworks and roots of trust that have registered it. And VCs always contain the ID of the issuer. There is currently a PR on the latest VC DMv2 draft documenting the actual ToU values used by the EBSI project. I did document how to solve this problem for verifiers in the OID4VP draft (which we implemented in the NGI Atlantic project), but I believe some or all of my text has been removed in the last few months when I was not actively participating in the WG. And my proposed PR was replaced by one adding the client_id scheme, which does not solve the problem. It should not be difficult to document how the same process can be used for wallet providers. Happy to help if needed.

[pmhsfelix]

Thanks for the responses. We seem to have multiple ways of dealing with this problem, however the currrent VCI spec doesn't provide any guidance. Achieving interoperability probably requires specific profiles, however the VCI should define the boundaries for those profiles.

I also have an additional concern: dealing with unknown clients has a significant impact on Authorization Servers, which typically only know how to respond to pre-registered clients:

• The first contact of a client with an AS may happen in different places, namely: authorization requests, token requests (when using pre-authorized codes), pushed authorization requests. Some of these are front-channel requests while others are back-channel requests.
• Having to deal with client trust establishment and client metadata discovery in all these endpoints adds significant complexity to an AS, specially if this requires the AS pulling information instead of the client pushing information to the AS.

A way to make this simpler for Authorization Servers is to require the pre-registration of these unknown clients via DCR (RFC 7591).

• Using DCR, the authorization requests, token requests, and push authorization requests would use client IDs known to the AS, so no discovery or trust establishment would need to happen at those points.
• Instead, these discovery and trust establishment activities would only happen on the DCR endpoint.
• This is not incompatible with the use of attestation-based mechanisms, which could still be used on the DCR endpoint and on other back-channel endpoints, such as the Token Endpoint or the Pushed Authorization Request Endpoint.
• The DCR protocol already has space for the client to send extra information (e.g. software_statement claim), which is used in some open banking profiles (e.g. Open Banking Brazil).

@sakimura @tlodderstedt WDYT?

[jogu]

I think having OID4VCI require pre-registration of wallets using DCR at the AS would overly limit adoption of the spec and create some fragility. It also would not relieve the AS from the burden of checking if the client can still be trusted so some complexity in the AS would still be needed. Italy have already made it clear they will use OpenID Federation.

Perhaps in some ecosystems some authorization servers will choose to pre-register all clients that are part of the trust list rather than dealing with creating records on the fly, but that feels like an implementation decision rather than something we should dictate in the spec.

[paulbastian]

Similar discussions came up at IETF. If this discussions is about DCR and client attestation, please move or keep in mind the discussion to https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/issues/61

[ju-cu]

@paulbastian no, it's not about client attestation, though client attestation can help to identify (and establish trust e.g. during DCR in) a client. This issue is about setting up the configuration for a client at the authorization server in a standardized manner, that is configure the redirect uris, supported algorithms, authentication methods and more (the client metadata) and assign it a client_id. Whenever the authorization server sees the client_id in requests, it can identify the configuration and apply rules accordingly. In OpenID4VP, the wallet can discover a Verifier's metadata via the client_id_scheme but as this issue states, there is no client_id_scheme for wallets in OpenID4VCI that the authorization server could use to discover the client metadata. So clients can register at the authorization server out of bound ("pre-register"), or via DCR. Or, use other means like client attestation. The latter provides a significant overhead for low assurance environments, imo.

ad Q1: I think, it's infeasible to require clients to register at all AS a-priory, so I agree with your assumption. ad Q2: No, DCR is not the only method right now to avoid pre-registration. You can also use client attestation based client authentication. DCR is probably the preferred way in a low assurance environment because you can get all the discovery and trust verification in a single place (no need to verify trust and perform cryptographic operations on every request).

[pmhsfelix]

My goal is not to make pre-registration usind DCR mandatory for VCI. However the current document is almost silent about this "client management/discovery" aspect, which IMO is very important for the use of verifiable credentials in open ecosystems. So I was wondering:

• Should the VCI spec just mention that this aspect will be defined in specific profiles, leaving the door open to multiple different mechanisms.
• Should the VCI spec go a bit further ahead, and identify some possible solutions without mandating them (e.g. DCR, OpenID Federation)?

I'm also concerned with the added complexity that some of these mechanisms may introduce on the AS, namely the support for automatic registration.

Finally, I'm also not yet convinced that attestation solves this issue completely, at least looking at the latest draft on https://vcstuff.github.io/draft-ietf-oauth-attestation-based-client-auth/draft-ietf-oauth-attestation-based-client-auth.html:

• The AS still needs to discover properties of the client, such as the allowed redirect_uri. A solution would be to convey them on the Client Attestation JWT.
• The AS also needs to know and trust information about the Client Attestation JWT issuer (Is it allowed to attest clients? For which client IDs? What is the key material?)
• Note that when using authorization code flows, the attestation only happens at the token request while some of the client properties, such as the redirect URIs, are needed on the authorization request, which happens before.

[jogu]

I have no issue with adding some non-normative text/guidance.

I agree that the attestation draft (whilst very useful) does not currently appear to solve the problem of initially registering the client_id/redirect uris/etc at the issuer

[paulbastian]

But does DCR solve that either? Both entities need to be in some trust list or similar mechanism and then client authentication could be sufficient

[jogu]

But does DCR solve that either? Both entities need to be in some trust list or similar mechanism and then client authentication could be sufficient

It can do, e.g. if a software statement is used (as is done in many Openbanking ecosystems) - https://www.rfc-editor.org/rfc/rfc7591#section-3.1.1

[tplooker]

@pmhsfelix I believe a mechanism where the client identifies via a URL like as proposed in https://mattrglobal.github.io/draft-looker-oauth-client-id-scheme/draft-looker-oauth-client-id-scheme.html is the most suitable, because the authorisation server needs to understand the capabilities of the client but doesn't necessarily need to have captured this is a seperate registration process. There is some discussion in that document as to why it is likely better then DCR such as preventing dead client registrations.

[andprian]

Is there a real need for a client_id in VCI? If not, why not make it optional?

[pmhsfelix]

client_id is required for the interaction with the AS, at least for the authorization_code grant. On the pre-authorized_codegrant, client_id is already optional (IINM). Note that for an OAuth 2.0 AS, all clients are identified with a client_id, even public clients.