Closed peppelinux closed 10 months ago
fmarino-ipzs
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago Just to be clear, the credential type Is the wallet instance attestation
Does dpop improve something in this flow or not? Why?
asharif1990
commented
1 year ago 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
commented
1 year ago 
tlodderstedt
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago @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
commented
1 year ago 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
commented
1 year ago @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:
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
commented
1 year ago @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
commented
1 year ago I have to admit I'm lost. What do you use the wallet attestation for? Do you have a sequence diagram?
peppelinux
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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:
asharif1990
commented
1 year ago 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
commented
1 year ago @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
commented
1 year ago @peppelinux Can you please explain why
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
commented
1 year ago @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:
peppelinux
commented
11 months ago
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 https://github.com/italia/eidas-it-wallet-docs/issues/14#issuecomment-1603346224