Detailed status assertions

[OR13]

Addressing:

#53 (comment)

The purpose of this pull request is to define the signed information which can be conveyed to a verifier, to clarify the constraints on verifier policies.

With other status list approaches, there is an ability to communicate a single boolean, multiple boolean, or enumerations.

With our approach here, we are not limited by the bitstring data structure, so dynamic state is less constrained.

This PR also highlights the current design decision to use alg = none, to signal revocation, without providing an assertion that can be consumed by a verifier.

There may be very legitimate reasons to prefer to return unsigned information for boolean status, but for complex status, unsigned information is more dangerous to consume.

I believe the specification should leave some of these decisions up to profiles.

[peppelinux]

The discussion is getting along the requirement to extend the status assertions to include different states.

there may be a brand new claim, boolean, saying it the status assertion points to a valid credential or to an invalid credential.
there may be the requirement to include an extendible json object to describe several failure state, when the related credential is not valid anymore

[peppelinux]

this PR aims to resolve the issue #60

[marinaado]

I do not understand the use cases that we are trying to support here. IMHO it would be very useful to give a use case that cannot be solved by boolean or enumerated list approach, and then give an example of how complex state solves it.

[OR13]

The purpose of a status assertion is to communicate an updated state, without reissuing the full credential.

Imagine a fast pass border clearance credential, where you can move quickly through a checkpoint when the following are true:

1. All ingredients in your product have not been recalled.
2. All ingredients suppliers, are not on a sanctioned entities list.
3. Your legal entity is recognized to be in good standing with countries A,B,C,D

Imagine that each of these status details are synchronized at different time intervals, and under different policies.

The credential is simply an identifier and a public key.

You don't need to reissue this credential, unless the hsm holding the private key breaks.

You do need a fresh status assertion, to cross the border, but it can be up to a day old.

Some verifiers may care about certain real-time status indicators more than others.

The issuer doesn't know the verifiers policy, so the issuer cannot pre compute a boolean or enumeration, the issuer can only supply the latest state associated to the public key bound to the credential.

[peppelinux]

To enhance the specification's flexibility and extendibility, it is proposed to introduce a mandatory parameter credential_status, set to True when the credential is fully operational and active. Verifiers should be required to check this parameter along with the typ value and the assertion's signature.

Additionally, an optional parameter, credential_status_description, could be introduced, allowing issuers to provide human-readable information about the credential_status.

This modification would allow the specification to accommodate future drafts or extensions aiming to elaborate on the data schema of the assertion. It would establish a consistent baseline to prevent misinterpretation and potential security issues related to complex credential statuses.

these future draft and any other possibility connected and allowed by this change could be further described in an dedicated annex, if @OR13 wants to bring some example and use cases that matters from his perspective

[OR13]

I think it is helpful for the issuer to indicate if they think the latest status information should be treated as breaking validity (like expiration or a tampered signature would), or if the new information is just an additional claim ( could be an updated counter for example).

It's always the verifiers choice to accept issuer claims, and dynamic state / status is just an issue claims that can change during the validity period of a credential.

I'm fine to add language recommending against complex state, because it is true that the more complex a credential the harder it is to write verifier policies and the more likely that policy errors could lead to processing errors.

Another alternative to complex state is refreshing the credential or requesting independent credentials and presenting multiple credentials in a predefined workflow.

[OR13]

I've marked this ready for review.

The general intention is to enable an issuer to convey status information that is not limited to boolean or enumerations.

Enumeration status are common in workflows, where items can proceed through several states, such as "submitted", "in-review", "accepted", "rejected".

complex state that is not boolean or enumeration is common in status updates that represent aggregations of signals, another example of where these show up is - https://blog.cloudflare.com/deep-dive-privacy-preserving-measurement

[peppelinux]

@OR13 see also these:

• [Credential Lifecycle] - Revocation with retroactive flag italia/eudi-wallet-it-docs#302
• [Credential Lifecycle] - Revocation italia/eudi-wallet-it-docs#264

[leifj]

I don't see any major issues here but I suggest rewriting the normative language about PII along the lines I suggested.

[leifj]

So this is the right sentiment but I think the way to express this is that a verifier MUST NOT be able to derive information about the credential or the subject that isn't already provided in a proof to the verifier.

[leifj]

Simply talking about PII doesn't cover all the cases you can screw up basically.

[leifj]

How do we represent a "pending" revocation?

[leifj]

Pending beeing neither valid or invalid...

[peppelinux]

pending is an half state, my pythonic mind says that 0.5 is not true

[OR13]

In the W3C Bitstring Status list, there is a purpose called "message" which is not revoked or suspended... You can use it to signal any message the issuer chooses.... Including pending.

The more I have thought about this, the more I conclude that credential status is a separate category of validity information... It's not as simple as being inside or outside a validity period... Or revoked or suspended being invalid and their opposites being valid.

I think it's better to allow the verifier to determine validity, and for the issuer to simply focus on clearly communicating.

[leifj]

so why don't we elliminate the boolean entirely and just have an IANA registry for the status semantic - the spec would register "valid" and "invalid" as two standard semantics. Everybody else get to define their own. The problem with mixing a boolean with "extra information" is that you get into a criciality issue: what if somebody defines a semantic that critically modifies the truthyness of the boolean. This is something that has plagued extensions in X509 btw.

[OR13]

I'm very supportive of aligning the status list and status assertion claims and semantics everywhere we can.

[OR13]

I filed #81

[peppelinux]

I support aligning the specs terms, since status assertions was born as a status list feature/extension

[marinaado]

@paulbastian could you please provide reference for the StatusList IANA Status semantics registration.

[paulbastian]

I refer to this section: https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#name-status-types
I just observed though that we are missing a corresponding subsection in the IANA as appendix, which I will fix shortly.

[leifj]

I suggest something along the lines of "MUST NOT contain information about the data subject (user) that isn't already made available to the validator"

[marinaado]

Is there a relation between the Status Assertion Errors and the Credential_status_validity being false?

While specification says that revoked credential should generate Status Assertion Error, the following example from the spec is IMHO conflicting that.

Shouldn't a revoked credential generate an Status Assertion Error response message with the Credential_status_validity being false?

{
    "alg": "ES256",
    "typ": "status-assertion+jwt",
    "kid": "w8ZOZRcx21Zpry7H-0VLBsH7Wf7WXb6TeK3qVMCpY44"
}
.
{
    "iss": "https://issuer.example.org",
    "iat": 1504699136,
    "exp": 1504785536,
    "credential_hash": "xnlAq6Ma8fgu1z4hdGphJnKLulaVHpLCFeZFUGpQ2dA",
    "credential_hash_alg": "sha-256",
    "credential_status_validity": false,
    "credential_status_detail": {
      "state": "suspended", // or "revoked"
    },

[OR13]

@marinaado your question is one of my original motivations for exposing this representation.

In other status mechanisms, a verifier can obtain an issuer signed status that is "negative" such as "revoked or suspended".

Getting a signed assertion that something is not valid is different than being unable to get a signed assertion that something is still valid.

In more complex state machines, where there are more states than valid, revoked, suspended... getting a signed assertion of "pending" or "in progress", or "6/10 items completed"... can be more useful to policy automation than an error.

I think the error responses make sense, when there is no status to provide back, or the issuer policy is to not provide a status for certain states.

Even in a more complicated status assertion system, the issuer might return errors at certain times of the day (too close to a rollover window), or for certain states, such as "update in progress", or "pending".

We should probably provide some guidance to implementers on when to choose "valid" or "error", and when to choose "latest status" or "error".

In the context of HTTP errors, I think of status assertion errors as coming in 2 forms:

5xx - issuer rejects the request for internal reasons beyond the control of the holder.
4xx - issuer rejects the request because the holder has made a mistake.

Regardless of what the issuer ultimately returns boolean, enumeration, or objects... I can still see some value in also returning 4xx or 5xx in some cases.

I hope this answers your question.

[OR13]

Suggested change

	- SHOULD NOT contain personal information about the User who owns
	the Digital Credential to which the Status Assertion refers.
	- SHOULD NOT contain information about the data subject (user) that isn't already made available to the validator.

[leifj]

what I am really looking for is a clear resolution to #31 here by aligning the language as best we can with that of the regulation which this proposal doesn't do imo.

[OR13]

Thanks for the pointer.

Let's unpack the requirements:

not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of transactions or user behaviour to be otherwise obtained, unless explicitly authorised by the user;

The key part of this is last bit.

If the user (holder) provides additional information to the issuer, the assertion can contain new information, including potential tracking.

In the case the holder discloses a status assertion or potentially even as fresh disclosure of a disclosable status assertion.. the holder controls what information other parties receive.

In status assertion the biggest privacy risk comes from issuer tracking, based on when fresh assertions are requested.

Justin mentioned this at the mic line in the oauth session at IETF 120.

We should provide guidance on the privacy trade offs.

[OR13]

I've revised the suggestion to match https://github.com/peppelinux/draft-demarco-oauth-status-assertions/pull/61/files#r1681325358

[marinaado]

@OR13 Yes it makes sense. Are you suggesting that we change the Status Assertion Errors section?

[peppelinux]

I suggest to have in this PR at least @leifj 's suggestion about "MUST NOT contain information about the data subject (user) that isn't already made available to the validator"

I didn't get what we should change about the status assertion errors, I am supportive in reducing them to only handle exceptions and errors about the status assertion error requests

I suggest to handle the language alignment in another PR, hopefully when this PR is merged, therefore having a full revision of the document

regarding the http status code, since we have decided to handle arrays of object where each request and response are about one or more of these, returning a 4xx or 5xx errors would not be related to the status assertions protocol but to deployments of httpd

[marinaado]

This PR should be merged, while the leftover work is moved to the following issues:

• Align vocabulary with status list draft #81 to address alignment of the credential_status_detail parameter vocabulary with the statusPurpose parameter of OAuth Status Lists specification.

• Align boolean validity claim #83 to revisit the decision to have the boolean validity claim with the status list approach, potentially dropping it in the future versions

• Remove credential status from Status Attestation error #85 to remove credential status from Status Attestation error

[marinaado]

There are several issues that we moved to issues #81, #83 and #85 85. Otherwise i am fine with this PR.