search

peppelinux / draft-demarco-oauth-status-assertions

OAuth 2.0 Status Assertions for Digital Credentials
Other
4 stars 5 forks source link

Detailed status assertions #61

Closed OR13 closed 6 days ago

OR13 commented 4 months ago

Addressing:

https://github.com/peppelinux/draft-demarco-oauth-status-attestations/pull/53#discussion_r1614083883

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 commented 4 months ago

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 commented 4 months ago

this PR aims to resolve the issue #60

marinaado commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

@OR13 see also these:

OR13 commented 2 months ago

@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.

marinaado commented 2 months ago

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

peppelinux commented 1 month ago

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 commented 1 week ago

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