RFC-010: Review

[kerk12]

No description provided.

[LeoneRiello74]

The document explains how to obtain the signing certificate information and how to authorize the creation of a signature, but the wallet is not used for the purposes mentioned above, i.e. authenticating to the QTSP remote signing service and/or authorizing the creation of a signature towards the QTSP remote signing service. Therefore, I do not understand the content of the summary and motivation clauses where it is mentioned that the EUDI Wallet is used as a means of user authentication and for enabling remote digital document signing using long-term certificates.

[andreasabr]

@kerk12 in the diagram at line 108 it feels like that is a part missing. After the PID presentation towards the RSS how can the next step be the Credential authz towards the RQES without any interim step? Am I missing something or are the provided information incomplete.

[andreasabr]

In Section 4.1: the sentence "Checks should be performed in order to make sure the presented document is valid and current (out of scope)." should be reformulated or even removed (since its anyway out of scope).

Further, it says: "The Signing Service should then use these attributes, along with data from the authentication context of the user to issue a QES Auth Credential (QESAC), including in its token claim a unique identifier or token, binding the user's profile to this VC.".

Does this mean that the QESAC contains besides the token also other attributes? If yes, we should include an example otherwise we need to reformulate the text.

The meaning of the paragraph VCT of QESAC is not clear to me and also shows that there are more parameters in the QESAC, therefore, a full QESAC example would be helpful.

[andreasabr]

In section 4.2.2 it says "The token inside the QESAC is valid and not recalled.". What does recalled mean in this context?

[andreasabr]

Section 4.4.1: Maybe we can simplify the heading to Signature Confirmation

[andreasabr]

In Section 4.4.2 it says: "The Signing Service will need to parse the auth.mode object of the user's credential to determine the mode of credential authorization:". a fully credential example highlighting this detail could help understanding this flow.

[andreasabr]

In Section 4.4.2 the RFC defines the two options for auth.modes. According to the description, all providers will have to support both. Should we consider making one option mandatory and the other one optional? This could help implementers to reduce implementation effort.

[kerk12]

@kerk12 in the diagram at line 108 it feels like that is a part missing. After the PID presentation towards the RSS how can the next step be the Credential authz towards the RQES without any interim step? Am I missing something or are the provided information incomplete.

@andreasabr You are right on this. The diagram needs updating (I may have forgotten to update it after the addition of the QESAC).

[kerk12]

@andreasabr

In Section 4.1: the sentence "Checks should be performed in order to make sure the presented document is valid and current (out of scope)." should be reformulated or even removed (since its anyway out of scope).

I'll be removing it since it's, as you say, out of scope.

Further, it says: "The Signing Service should then use these attributes, along with data from the authentication context of the user to issue a QES Auth Credential (QESAC), including in its token claim a unique identifier or token, binding the user's profile to this VC.".

Does this mean that the QESAC contains besides the token also other attributes? If yes, we should include an example otherwise we need to reformulate the text.

No, I'm just saying (incorrectly worded) that the token claim of the QESAC should be binded to the user. I'll reformulate.

The meaning of the paragraph VCT of QESAC is not clear to me and also shows that there are more parameters in the QESAC, therefore, a full QESAC example would be helpful.

As I said above, there aren't any parameters on the QESAC other than the token and, optionally, the credential_id. I'll be reformulating the text of this section as it's not that well written. I'll be putting the claims in a table to help with understanding. What I'm saying on the VCT part of the credential is that, since the QESAC of a Signing Service A cannot and should not be used with Signing Service B, the VCT can be set by each signing service provider.

[kerk12]

In Section 4.4.2 the RFC defines the two options for auth.modes. According to the description, all providers will have to support both. Should we consider making one option mandatory and the other one optional? This could help implementers to reduce implementation effort.

We can make one mandatory and the other optional. The simplest one to implement would be explicit auth. I think this is the one that should be made mandatory. What do you think?

[kerk12]

In section 4.2.2 it says "The token inside the QESAC is valid and not recalled.". What does recalled mean in this context?

Say that a QESAC is compromised for some reason, the signing service can mark the QESAC as recalled and the signing request would be rejected.