extend use beyond authorization servers

[peppelinux]

According to RFC7521 this draft aims to give specification about how to get authenticated with an AS, as we read in the introductory text

[RFC7521] defines a way for a client to include an assertion in a token request to an authorization server for the purposes of client authentication. This specification uses this framework to define a new assertion type that provides a way for a client instance to authenticate itself with the authorization server through an assertion that is bound to a public key (for proof of possession).

If the usefulness and purpose of this draft is clear, at the same time we perceive a great potential that could also be useful in other contexts.

Lately there has been a lot of talk about the use of the nonce as a definitive prevention against replay attacks, and the importance of the nonce endpoint for issuing these is often discussed.

In the background we have the emerging wallet ecosystem which proposes reversed roles at different times, where the wallet is a client in the issuance phase towards a credential issuer which is an AS, while it is a sort of AS in the presentation phase towards the Relying Party.

This draft could enable the authentication of a client (wallet) to a third party (either this AS or RP) before obtaining the nonce.

the possible nonce endpoint could present itself as a protected endpoint, the nonce should only be issued to authenticated parties.

This generalization would require greater flexibility compared to the current purposes of the draft, which envisages its use only when the audience is an AS, while it could also be an RP, where the wallet instance attestation with PoP can be provided before any kind of transaction takes place (allowing the RP to discover the wallet capabilities before issuing the signed request object).

[David-Chadwick]

From a trust perspective I think that issuing and presentation of credentials are different. The user/wallet typically trusts the issuer, otherwise why would it ask for a credential from it? OTOH, the user/wallet cannot trust any random RP that it connects to. Therefore the user/wallet should expect the issuer to authenticate itself first to the user/wallet, before authenticating itself to the issuer. OTOH the user should expect the verifier to identify itself first, so that it can determine if this verifier is trustworthy, before progressing any further with authentication or capability determination.

[peppelinux]

I fully agree with you @David-Chadwick, in any cases the parties must establish trust before any protocol specific flow (issuance or presentation) may happen.

this issue aims to use an verifiable attestation based approach not just for client-AS (issuance) but also from AS-client (presentation), where the flow is conditioned by which entity has availability of endpoints (CI, RP) and which one not (wallet instances)

[fbaud]

@David-Chadwick @peppelinux, I agree that issuing and verifiying are entirely different from a trust perspective. But my angle would be to emphasize this from the issuer/verifier perspective:

• as an issuer, I want to trust the wallet I'm issuing a credential to. At the minimum, I want to check that the wallet has received some form of authorization to receive a credential that was defined by a user agent (a widget in our case at Primus Money)
• as a verifier, I may just want to identify who is presenting a credential so that I can reconcile it with my backend data server. Most of the time, identification could be self-contained within the presentation itself. The more empediment (excessive authentication requirement) for the wallet to provide a credential, the less useful it is for the verifier.

I agree that from the wallet perspective, the angle is the symetric: more requirements on the verifier to identify itself, no excessive requirement on the issuer for most of the types of credentials.

I must stress that in our architecture, we have the additional element that is the widget which is the first interface between the user and the issuer/verifier. We are in a context where the widget connects to a SaaS infrastructure and we have again different trust requirements between issuing and verifying:

• for issuing, the widget needs to authentify to specify the type of credentials it authorizes the SaaS server to issue
• for verification, except the concerns about Denial Of Service, the requirement to authentify are much less stringent and we can imagine workflows where we let anyone who wants to submit a presentation to let them do that.

[peppelinux]

@fbaud I agree with you and I'd buy also this

Most of the time, identification could be self-contained within the presentation itself. The more empediment (excessive authentication requirement) for the wallet to provide a credential, the less useful it is for the verifier.

At the same time the RP should know the wallet capabilities to know which are the supported sign and enc alg (and enc), if the wallet solution supports the presentation_definition_uri and so on.

In italy we use the wallet instance also to carry these capabilities, here an example

this feature consolidates how a wallet capabilities discovery is required for a good interoperability, let's consider that a signature alg may be discovered vulnerable or the continuous technology advancement and innovation that will introduce periodically new features and algs.

I believe that having a wallet capabilities discovery process, seamless in both issuance and presentation, is a future proof approach

[fbaud]

@peppelinux I think that the discovery process between the wallet and the server can be done without authentication.
It is more part of a protocol negotiation than part of a transaction. Transaction may need authentication, but for the verifier the point was more: "give me all you can give and I'll sort it out". While for the issuing, after possibly negotiating what alg, trust_chain, credential format,.. will be used, the server may need to authenticate the wallet (or check that it has the right authorisations) before delivering the credential. But nevertheless, we should also imagine that a wallet can request a credential without having to authenticate (like for a server delivering a timestamped credential for a process requiring a dead-man switch).

[peppelinux]

@fbaud How an RP discovers the wallet capabilities is something that should happen before the issuance of the signed request object. At the same time the RP must be sure that the WIA is in the legitimate possession of the Holder, with the authentication through the WIA+PoP

this approach would fit with the nonce_endpoint discussed here: openid/OpenID4VCI#71 (comment) where in addition we protect the issuance of the nonce with a wallet instance authz

But nevertheless, we should also imagine that a wallet can request a credential without having to authenticate (like for a server delivering a timestamped credential for a process requiring a dead-man switch).

yes, the autentication would be quite modular and for Type 1 and some Type 2 credentials, according to the required LoA

[David-Chadwick]

The verifier must trust the issuer, otherwise it cannot accept the issued credentials that are held by the user/wallet, regardless of the capabilities of the wallet. However, we know that the wallet must have the capability to accept the credential from the issuer.
Consequently the verifier should obtain the meta data of the issuer, and this will provide the verifier with (possibly a superset of) the capabilities of the wallet. Thus I think it is a false requirement for the verifier to determine the capabilities of the wallet. Rather it should determine the capabilities of the issuer. If the verifier is capable of accepting all of these capabilities, then it knows that it can accept the credential from the wallet, regardless of what capability the wallet has. Now, I accept that a wallet may only support a subset of the capabilities of the issuer, but providing the verifier can support all the capabilities of the issuer this is not be a problem. The problem arises if we have both a verifier and a wallet that only support a subset of the capabilities of the issuer, and these are disjoint sets. But in this case there is little point in the verifier determining the capabilities of the wallet, as it cannot interwork with it. Thus the verifier should request the credential from the wallet using (a subset of) the capabilities of the issuer, and see if the wallet can provide it in this format. I don't believe the verifier needs to pre-determine the capabilities of the wallet.

[peppelinux]

What if ...

1. The wallet instance encrypts the presentation response with an enc alg that's not supported by the verifier?
2. The wallet instance doesn't support presentation_definition_uri? (see presentation_definition_uri_supported)
3. The wallet instance doesn't support a specific vp format? (see vp_formats_supported)
4. The wallet instance has to provide the authorization_endpoint to the verifier? (... Can be custom URI scheme, or Universal Links/App links ...)

then, having these previous, why the wallet capabilities discovery would be a false requirement?

[David-Chadwick]

@peppelinux In answer to the above

1. This is a (lack of) capability of the verifier. If it is constrained in this way it should inform the wallet in the request for the VP or via its metadata
2. The wallet will return an error to the RP
3. It is most likely that the wallet will support the same formats for VCs as for VPs. I think it highly unlikely that a wallet will support say a JWT VC and not a JWT VP. Thus the verifier can infer what vp format(s) will be supported by seeing what VC format(s) the issuer provides to the wallet.
4. In our interworking tests the RP had to have a web page with the correct wallet endpoints so that the user could click on the correct one. In the case of a cloud wallet, the user had to enter this URL to the RP (since the RP cannot know the endpoints of all (or any) cloud wallets. If the RP knows nothing about the user's wallet how do you expect the two to communicate? In our opinion, the connection had to be initiated by the user, and the user knows the endpoint of its own wallet

[peppelinux]

I got your point @David-Chadwick and I'd make your also mine, however I'm aware that having a proper discovery we would remove any fault, errors and failed transaction that may happen in the real world, in particular with an open ecosystem where different tecnologies and implementations profiles will end to be mixed. I see a future where an EIDAS Wallet solution may implements external features and then also did resolvers and additional capabilities. This would build an open ecosystem where interop and capabilities discovery represent a concrete and future proof requirement

Not at least, preventing faults saves both users time and electricity :-)

[paulbastian]

I agree with @David-Chadwick here mostly. My observations are:

• The Verifier will most certainly know which credentials he requires and the technical requirements are clear from the issuers, that the Verifier will accept
• Wallet Capabilities and Wallet Attestations is not necessarily the same concept, indeed the Verifier metadata may be transmitted unsigned as well today in OpenID4VP
• Wallet technical capabilities should be omitted or very constrained to not open up privacy issues
• if the technical capabilities of the Wallet and Verifier do not match, this will ultimately result in an error, no matter if the Verifier detects the capabilities or not

As this discussion is happening in the Client attestation draft, I would like to limit this discussion mostly to the question whether we need client authentication for Wallet-Verifier interaction and what would be necessary for this draft to accomplish this