FIWARE / trusted-issuers-list / 95

88%

push

github

Topic/order scoped credentials (#28)

* Scope credentials to what granted them

A credential entry was identified by its content, so revoking one grant removed a
credential another grant still required. That is a latent defect today - two
product orders can configure the same credential - and it becomes the normal case
once a ServiceSpecification shared by several products carries the
configuration.

Credentials now carry the identifier of whatever granted them, and grants are
addressed by it:

* PUT /issuer/{did}/credential?scope=<id> sets the credentials of one scope to
  exactly the ones provided, leaving every other scope - and every credential
  managed through the issuer endpoints, which carries no scope - untouched.
  Replacing rather than appending makes the call idempotent, which matters
  because the callers react to notifications that are redelivered on failure.
  The issuer is created when unknown, so callers need no create-or-update branch
  and cannot race on one.
* DELETE /issuer/{did}/credential?scope=<id> removes the credentials of one
  scope. The issuer itself is kept even when nothing remains, so an issuer
  somebody else manages is not deleted as a side effect. An issuer without
  credentials is trusted for nothing, which is the same outcome as before.
* A blank scope is rejected: it would create a grant no revocation can address
  precisely, which is the problem the scope exists to solve.

The scope is deliberately NOT part of the API models. Both registry projections
serialize the same CredentialsVO - v4 into the attribute body and hash, v5
additionally into the attribute id, which is a hash of those very bytes - so a
scope in that model would publish grant identifiers in a world-readable registry
and change every v5 attribute id. It travels as a query parameter instead and
lives only on the entity. Two regression tests pin that down by comparing the
projections of an unscoped and a scoped credential.

Because one credential can... (continued)

155 of 195 branches covered (79.49%)

Branch coverage included in aggregate %.

626 of 696 relevant lines covered (89.94%)

0.9 hits per line