Wallet Instance Attestation and oauth-attestation-based-client-authentication

[peppelinux]

It seems to me that we can definitively say that the flow proposed in this PR is not compliant to:

oauth-attestation-based-client-authentication

we should work on an analysis on the impacts and implication of this @asharif1990 @giadas @grausof. In which parts the absence of DPoP in oauth-attestation-based-client-authentication is considerable a requirement or overkill?

Originally posted by @peppelinux in #14 (comment)

[fmarino-ipzs]

It is a requirement for some credentials (for example the PID, or in general all credentials of type 1 I would say). For other credentials is overkill. Assuming that we must consider at least a PID for the wallet activation, the wallet solution must support this security mechanisms.

[asharif1990]

Yes. We design it based on the simple assertion based client authentication method RFC7521 as in our case we are genrating new keys for DPoP. If we arre foing to conaider this method only to simplify our life to avoid generating a new key pair, I see the following problem: if the attestation become invalid then we have to revoke the bounded access token and in addition maybe the credentials that are obtained using that token. However, if it is a no for this purpose, what benefits it brings that you cannot achived with the simple assertion based cline authentication?

[asharif1990]

We have a PAR request that is signed by using the same key that is created during the setup phase and its attested public key is inside the wallet instance attestation. In this way implicitly we can achieve the same purpose of that spec even before arriving at the token request. However, if you see other benefits of using it, I am totally fine with the modification of the flow.

[peppelinux]

Just to be clear, the credential type Is the wallet instance attestation

Does dpop improve something in this flow or not? Why?

[asharif1990]

Maybe, we are not on the same line. I thought you are referring to the wallet solution and specifically the PID Issuance Flow. but from your last comment, it seems not. can you clarify this point by pointing to the file?

[peppelinux]

Indeed, here
https://github.com/italia/eidas-it-wallet-docs/pull/14/files#

[tlodderstedt]

We design it based on the simple assertion based client authentication method RFC7521 as in our case we are genrating new keys for DPoP.

How do you protect the assertion from replay?

[tlodderstedt]

According to https://italia.github.io/eidas-it-wallet-docs/wallet-instance-attestation-SIW-151/en/wallet-instance-attestation.html, your assertions are key bound (cnf). Where is the disconnect?

[peppelinux]

How do you protect the assertion from replay?

According to https://italia.github.io/eidas-it-wallet-docs/wallet-instance-attestation-SIW-151/en/wallet-instance-attestation.html, your assertions are key bound (cnf). Where is the disconnect?

For this aspect the two approaches are the same, since they have holder key binding using cnf.

Well, it seems to me that this issue was bad addressed by me, since we're not using oauth-attestation-based-client-authentication. Anyway, the interesting question before closing this issue would be:

Where oauth-attestation-based-client-authentication could be useful in the flows we have designed for the italian implementation? Since we didn't seen any use cases for our implementation profile

[peppelinux]

@tlodderstedt do you have any other consideration?
It seems to me that this issue was not addressed well (my bad) and I hope that the discussion has clarified and your questions has been answered

[tlodderstedt]

draft-looker-oauth-attestation-based-client-authentication defines an new OAuth client authentication method. It defines how an OAuth client can authenticate with an OAuth AS using an attestation and a proof of possession of the bound key. That mechanism can be used at the token endpoint and for PAR. I would assume you can used it to present your wallet instance attestation.

[peppelinux]

@tlodderstedt it's something we're working on, the context is the following:

request_uri is protected
solution: DPoP or RFC7521 (now in the specs we have DPoP)
concerns:

• request_uri mandates the http method GET, while RFC7521 (then draft-looker-oauth-attestation-based-client-authentication) is traditionally used with HTTP POST.
• rfc7521 is used by a client to be authenticated to an AS, while in our case the request_uri is provided by the client and the wallet instance is the AS

request_uri is not protected
This is by default, anyway if the Wallet Instance provides its attestation to the RP this latter is then able to attest the security level and the capabilities of the wallet. If not provided the RP assumes a standard set of capabilities and a low security level

If I understand well, you're suggesting that a RP would expose a token endpoint to enable rfc7521?

[fmarino-ipzs]

@tlodderstedt probably you are referring to the Wallet Instance Attestation Presentation during the PID Issuing. In this case, yes you are right, we could use the draft-looker-oauth-attestation-based-client-authentication. Actually it seems to us that using rfc7521 is the same because we use the signed request object as a proof and the wallet_instance_attestation as the client_assertion.
During the PID presentation to an RP the situation is slightly different since we have a request_uri endpoint which is a protected resource and not a token endpoint neither an authorization endpoint. This is what @peppelinux pointed out in the comment.

[tlodderstedt]

I have to admit I'm lost. What do you use the wallet attestation for? Do you have a sequence diagram?

[peppelinux]

Yes Torsten

Here the issuance
https://italia.github.io/eidas-it-wallet-docs/en/pid-issuing.html#detailed-flow

Here the openid4vp flow, where the request uri has dpop to get the wallet instance attestation (rfc7521 as an alternative)
https://italia.github.io/eidas-it-wallet-docs/en/relying-party-solution.html#remote-cross-device-flow

[tlodderstedt]

Here the issuance
https://italia.github.io/eidas-it-wallet-docs/en/pid-issuing.html#detailed-flow

I guess you use a RFC 7523 client assertion (not RFC 7523). How do you prevent replay of such an assertion?
Can you share an example of the wallet instance attestation?
Would it be possible to split the credential issuer metadata in modular files (openid-credential-issuer vs entity configuration)?
How do you represent the issuer keys in the SD-JWT VCs?

Here the openid4vp flow, where the request uri has dpop to get the wallet instance attestation (rfc7521 as an alternative)
https://italia.github.io/eidas-it-wallet-docs/en/relying-party-solution.html#remote-cross-device-flow

Well, this is a custom version of request_uri with an additional authentication mechanism. Can you please share an example of the GET request?
May I ask you why you use a DPoP token for that purpose? I'm asking since DPoP is not about authentication of the requesting party but proof of possession of a (typically) ephemeral key.

[peppelinux]

replay attack
Good catch, added jti here

@fmarino-ipzs we have the duplication of the client assertion in both POST parameters and signed request, I suggest to give some consideration about this choice, if required also in the issuance section (a .. note ::)

WAI example
here: https://italia.github.io/eidas-it-wallet-docs/en/wallet-instance-attestation.html#detail-design (we need to fix the headings)
or better here: https://github.com/italia/eidas-it-wallet-docs/blob/versione-corrente/docs/en/wallet-instance-attestation.rst#signature

openid-credential-issuer vs entity configuration
for interoperability purpose is always better to have as much well-known endpoint as possible, considering that the EC is a signed envelope, nothing prevents to the implementers to have also openid-credential-issuer (example of something we know well: https://trust-anchor.oidc-federation.online/oidc/op/.well-known/openid-configuration). The sole condition to satisfy is that their content must be the same. The trust resolution mechanism is up to the trust verifier in accordance with the established trust model.

How do you represent the issuer keys in the SD-JWT VCs?
JWS trust_chain and kid header parameters, we're also in favor to put aside the x5c parameter for the best interop, since we use the Federation API for the automatic issuance of X.509 certificate that ISO 18013-5 forces us to have.

GET request
Please consider that:

1. the request_uri is not a protected endpoint, it optionally allow the submission of the walletinstanceattestation using DPoP or RFC7521
2. example here
3. We started with the consideration that WAI is an attestation is ephemeral, since:
   • it is issued periodically, it expires very often
   • it should not be linked to the same key of the PID/EAA holder key binding
4. We was on the way to replace DPoP with RFC7521 but before doing that we have decided to consolidate the first release and start discussion. For this purpose it's important for us give the requirement that the RP should know the wallet capabilities before issuing the presentation request, if this wouldn't be possibile the RP would assume a static set and a low assurance about the security of the wallet instance (this discussion is also here: https://bitbucket.org/openid/connect/issues/1967/openid4vp-wallet-instance-metadata)

[asharif1990]

We design it based on the simple assertion based client authentication method RFC7521 as in our case we are genrating new keys for DPoP.

How do you protect the assertion from replay?

As the Wallet Instance Attestation contains the public key of the Wallet Instance (cnf) and the Wallet Instance is going to sign the request object in the PAR with the corresponding private key, we believe that this protects against a replay of the assertion from an attacker. Does it make sense to you? @giadas @tlodderstedt

[tlodderstedt]

@asharif1990 I understand. This means (at least conceptually) you are inline with https://datatracker.ietf.org/doc/html/draft-looker-oauth-attestation-based-client-auth. Could you use this draft as is?

[tlodderstedt]

@peppelinux Can you please explain why

1. the wallet capabilities of the wallet need to be asserted by a 3rd party and
2. why you assume the capabilities vary across wallets / wallet instances. I'm asking since this would be a big issue for interoperability.

The reason I'm asking is I'm deeply concerned about the wallet needing to authenticate with each and every party as this either requires a static certificate (super cookie), or a backend service (no offline), and/or a large batch of ephemeral wallet attestations. Those are all limiting factors, I therefore would reduce the need for authentication to the bare minimum.

[peppelinux]

@peppelinux Can you please explain why

1. the wallet capabilities of the wallet need to be asserted by a 3rd party and

the wallet provider is a trusted third party, since it is part of the federation and being accredited by an accreditation body.
the wallet provider attests the wallet instance capabilities, these are related to both security and interoperability.

differently the wallet instance would self issue its metadata, are you in favor of this solution? This would issue the requirement to have two attestations that could be a single one instead: the WIA -> more efficient.

I mean that since the wallet instance metadata are ddefined in the wallet solution, it doesn't make sense that the wallet instance should self issue its metadata, since its user doesn't have any power on the definition on that. That's why I suggest to have these issued by wallet provider, in the WIA

2. why you assume the capabilities vary across wallets / wallet instances. I'm asking since this would be a big issue for interoperability.

I have a vision of a wallet that could work on both federated systems and open systems, where at a global scales different algorithms and capabilities are supported or not supported. I'm not in favor of arbitrary assumptions about what the capabilities should be for the entire ecosystem, even because there may be some cases where an eu member states may decide to extend or reduce some feature of the solution with the requirement to not break the interop.

Having worked for years with SAML2 and OIDC and OAuth2 with metadata, I have concerns about abandoning this approach that worked for years and solved several interop issues by design

The reason I'm asking is I'm deeply concerned about the wallet needing to authenticate with each and every party as this either requires a static certificate (super cookie), or a backend service (no offline), and/or a large batch of ephemeral wallet attestations. Those are all limiting factors, I therefore would reduce the need for authentication to the bare minimum.

the static certificate is not a super cookie, since the WIA is ephemeral and bound to specific keys issued by the wallet instance for that. the WIA in the authentication phases solved two requirements:

1. wallet instance metadata discovery, if the WIA will be extended with metadata/capabilities as I suppose to
2. wallet revocation mechanisms without the requirement to revoke PID/(Q)EAA, since the attestation/credentials MUST not be linked, then neither their revocation should produce a domino effect. by presenting a WIA to a RP this latter has the proof that the wallet is secure and not revoked, differently even if the PID/QEAA is not revoked these should not be presented with a revoked WIA

[peppelinux]

FYI
#130 (comment)