docs: remote QESEAL Conformance Specification - #198
Conversation
There was a problem hiding this comment.
Thanks for the first iteration @hiddedorhout-cb!
Raising a few questions regarding the ability to still keep the SAD under sole control of the legal person, avoiding risks that the AS has sufficient data to take over control.
|
|
||
| **Authorization must always originate from an AR wallet authentication.** The AR authenticates via their EUDI Wallet Unit and establishes an authorization at the RSSP's AS. The question is the granularity of that authorization: | ||
|
|
||
| - **Grant-based authorization** (primary): the AR issues a standing authorization grant, bounded by a validity period and/or a maximum seal count. The SA creates seals autonomously within the grant without further AR interaction. The grant is the AR's explicit delegation decision; individual seal operations are system-to-system. |
There was a problem hiding this comment.
| - **Grant-based authorization** (primary): the AR issues a standing authorization grant, bounded by a validity period and/or a maximum seal count. The SA creates seals autonomously within the grant without further AR interaction. The grant is the AR's explicit delegation decision; individual seal operations are system-to-system. | |
| - **Session authorization** (primary): the AR issues a standing authorization grant, bounded by a validity period and/or a maximum seal count. The SA creates seals autonomously within the grant without further AR interaction. The grant is the AR's explicit delegation decision; individual seal operations are system-to-system. |
In both granularities, the AR provides an authorisation grant.
|
|
||
| Both patterns require that the AS has received a genuine AR wallet authentication before issuing any SAD. The SA's service credentials alone are never sufficient to authorize seal creation. | ||
|
|
||
| > **NOTE_QSEAL_01** From the perspective of ETSI EN 419 241-1 [9], grant-based authorization corresponds to SCAL1 at the level of individual signing operations (no per-signing Signature Activation Protocol). However, it differs fundamentally from the `authMode: implicit` case excluded by this specification: grant-based authorization requires a traceable, wallet-authenticated human decision with defined limits, whereas implicit authorization relies solely on static service credentials provisioned during onboarding. The WE BUILD requirement is that sole control must trace to an AR wallet authentication, regardless of whether that authentication occurs per operation or per grant period. |
There was a problem hiding this comment.
For QESeal, we should still target SCAL2.
|
|
||
| 1. Authenticates to the RSSP's AS using OAuth2 client credentials to obtain a `service_access_token`. | ||
| 2. Computes the document hash(es) to be sealed. | ||
| 3. Calls `POST /credentials/authorize`, presenting the grant token alongside the `credentialID`, `hash` values, and `numSignatures`. The AS verifies the grant is valid (not expired, not exhausted) and issues a SAD bound to the submitted hashes. |
There was a problem hiding this comment.
This means that the AS has all information to create the SAD, potentially affecting sole control.
Alternatively, could the SA create the SAD locally? This would reduce the role of the AS to just support in authenticating the AR and providing scoped access to the SA, but would move the responsibility of creating the SAD to the SA. Perhaps the AS could assist the SA by providing some of the data required to create the SAD, such as an identity assertion recognised by the QSCD.
| ## 6.3 PIN/OTP Authorization Flow | ||
|
|
||
| This flow applies when the seal credential has `authMode: PIN` or `authMode: OTP`. It does not involve the WU and is included as a baseline interoperability requirement for RSSPs and SAs that do not use wallet-based authentication. |
There was a problem hiding this comment.
Do we need this within WE BUILD?
|
|
||
| RSSPs MUST: | ||
|
|
||
| 1. Expose a CSC API v2.2 [1] compliant interface including `GET /info`, `POST /credentials/list`, `POST /credentials/info`, `POST /credentials/authorize`, and `POST /signatures/signHash`. |
There was a problem hiding this comment.
Should we not expose the OAuth 2 authorization endpoint, instead of credentials/authorize?
|
Nice work on the remote QESeal conformance specification, Hidde. Here are my comments on the draft: Section 4: Add SAM (Signature Activation Module). Section 6.1.2: The SAM needs to validate the SAD before accessing the RQSCD for creating the QESeal. Section 6.3: PIN or OTP is not SCAL2 compliant. References: Add ETSI TS 119 431-1 and EU CIR 2025/1567. |
4 participants
No description provided.