-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detailed status assertions #61
Changes from 22 commits
c99c696
1696d3d
8ed71d4
9e6e06c
b6c6954
4e14ab8
acdc495
44276b5
f201a8e
b8c7314
418f232
7455156
3003acd
5d9c4ca
1e15782
79709aa
1d878b1
465dcbb
68e4fac
b00b9bf
42526e6
e6239f5
425868d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
|
@@ -111,14 +111,15 @@ These assertions are periodically provided | |||||||
to holders, who can present these to verifier along | ||||||||
with the corresponding digital credentials. | ||||||||
The approach outlined in this document | ||||||||
makes the verifier able to check the non-revocation of a digital credential | ||||||||
makes the verifier able to check the status, | ||||||||
such as the non-revocation, of a digital credential | ||||||||
without requiring to query any third-party entities. | ||||||||
|
||||||||
--- middle | ||||||||
|
||||||||
# Introduction | ||||||||
|
||||||||
Status Assertions ensure the non-revocation of digital | ||||||||
Status Assertions show the status of digital | ||||||||
credentials, whether in JSON Web Tokens (JWT) or CBOR Web Tokens (CWT) | ||||||||
format. Status Assertions function | ||||||||
similarly to OCSP Stapling ([RFC6066]), allowing clients to present to the | ||||||||
|
@@ -247,7 +248,7 @@ the expiration datetime of the Digital Credential; | |||||||
- MUST enable the offline use cases by employing validation using | ||||||||
a cryptographic signature and the cryptographic public key of the | ||||||||
Credential Issuer. | ||||||||
- MUST NOT contain personal information about the User who owns | ||||||||
- SHOULD NOT contain personal information about the User who owns | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hmm, thats undermining one of my use cases. Lets imagine a truck that can be loaded with different products, and each product has a different weight. The truck is empty waiting to be loaded, it is loaded with copper ore, it drives over a weighing station which creates a status assertion for the truck that asserts: copper, weight. The rest of the truck credential may have an "unloaded weight", but it won't have "copper". Let me give a personal credentials use case that centers around new PII disclosures as well. Lets say a person has no children when their credential is issued, but a few days later then have twins. The status assertion could be: children: true, or children: 2 ... in either case, it would be new information to a verifier. If your point is that "determining what is PII is a can of worms"... I agree. I might recommend we simple avoid the discussion of PII outside of security considerations, and treat the status assertion as conveying information which the issuer can only provide about the subject after the credential has been issued and bound to the subjects public key... this information could be related to time or location or changes in physical traits, the subject of a credential is not necessarily a natural or legal person... see security considerations section __ for guidance on informed consent for personal information related to natural persons, etc.... I've offered an alternative here: https://github.com/peppelinux/draft-demarco-oauth-status-assertions/pull/61/files#r1682850960
OR13 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
the Digital Credential to which the Status Assertion refers. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the pointer. Let's unpack the requirements:
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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've revised the suggestion to match https://github.com/peppelinux/draft-demarco-oauth-status-assertions/pull/61/files#r1681325358 |
||||||||
|
||||||||
# Proof of Possession of a Credential | ||||||||
|
@@ -268,7 +269,8 @@ guidance for concrete implementations utilizing common proof of | |||||||
possession mechanisms. This includes, but is not limited to: | ||||||||
|
||||||||
1. Having the digital representation of the Digital Credential (the bytes). | ||||||||
2. Controlling the confirmation method of the Credential, using the Credential's `cnf` parameter. | ||||||||
2. Controlling the confirmation method of the Credential, | ||||||||
using the Credential's `cnf` parameter. | ||||||||
|
||||||||
The essence of requiring proof of possession over the Credential | ||||||||
through the confirmation method, such has proving the control of the | ||||||||
|
@@ -548,6 +550,7 @@ where the format is JWT. | |||||||
"exp": 1504785536, | ||||||||
"credential_hash": $hash-about-Issuer-Signed-JWT, | ||||||||
"credential_hash_alg": "sha-256", | ||||||||
"credential_status_validity": true, | ||||||||
"cnf": { | ||||||||
"jwk": {...} | ||||||||
} | ||||||||
|
@@ -570,6 +573,7 @@ The Status Assertion MUST contain the parameters defined below. | |||||||
| **exp** | UNIX Timestamp with the expiration time of the JWT. It MUST be greater than the value set for `iat`. | {{RFC9126}}, {{RFC7519}}, {{RFC7515}} | | ||||||||
| **credential_hash** | Hash value of the Digital Credential the Status Assertion is bound to. | this specification | | ||||||||
| **credential_hash_alg** | The Algorithm used of hashing the Digital Credential to which the Status Assertion is bound. The value SHOULD be set to `sha-256`. | this specification | | ||||||||
| **credential_status_validity**| Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. This parameter is REQUIRED, and the Verifier MUST verify its presence and value to assess the Credential's validity. | this specification | | ||||||||
OR13 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
| **cnf** | JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. | {{RFC7800}} Section 3.1, {{RFC8747}} Section 3.1 | | ||||||||
|
||||||||
|
||||||||
|
@@ -676,6 +680,123 @@ may not always coincide with the actual usability of a Digital Credential, | |||||||
allowing Verifiers to examine and make educated conclusions based on a | ||||||||
variety of scenarios. | ||||||||
|
||||||||
# Detailed Status Assertions | ||||||||
|
||||||||
Status Assertions can introduce a more accurate level of detail, and therefore not necessarly limited to simple boolean information. | ||||||||
This enables Verifier policies to be conditioned on the presence of secured information, instead of the absence of information. | ||||||||
This section proposes syntax to support detailed assertions. | ||||||||
The `credential_status_validity` claim MUST be present and be either `true` or `false`. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How do we represent a "pending" revocation? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Pending beeing neither valid or invalid... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm very supportive of aligning the status list and status assertion claims and semantics everywhere we can. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I filed #81 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I support aligning the specs terms, since status assertions was born as a status list feature/extension There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @paulbastian could you please provide reference for the StatusList IANA Status semantics registration. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I refer to this section: https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#name-status-types |
||||||||
The `credential_status_detail` claim MAY be present and if present MUST be an object. | ||||||||
The semantics of the claims within the `credential_status_detail` object are determined by the Credential Issuer. | ||||||||
|
||||||||
An example of a boolean status is: | ||||||||
|
||||||||
~~~ | ||||||||
{ | ||||||||
"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": { | ||||||||
"revoked": false, | ||||||||
"suspended": true, | ||||||||
peppelinux marked this conversation as resolved.
Show resolved
Hide resolved
OR13 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
}, | ||||||||
"cnf": { | ||||||||
"jwk": { | ||||||||
"alg": "ES256", | ||||||||
"kty": "EC", | ||||||||
"crv": "P-256", | ||||||||
"x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc", | ||||||||
"y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk" | ||||||||
} | ||||||||
} | ||||||||
} | ||||||||
~~~ | ||||||||
|
||||||||
An example of an enumeration status is: | ||||||||
|
||||||||
~~~ | ||||||||
{ | ||||||||
"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" | ||||||||
}, | ||||||||
"cnf": { | ||||||||
"jwk": { | ||||||||
"alg": "ES256", | ||||||||
"kty": "EC", | ||||||||
"crv": "P-256", | ||||||||
"x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc", | ||||||||
"y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk" | ||||||||
} | ||||||||
} | ||||||||
} | ||||||||
~~~ | ||||||||
|
||||||||
An example of dynamic status using a small matrix: | ||||||||
|
||||||||
~~~ | ||||||||
{ | ||||||||
"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": true, | ||||||||
"credential_status_detail": { | ||||||||
"preferences": [[1, 0.25, 0.76 ...] ...] | ||||||||
}, | ||||||||
"cnf": { | ||||||||
"jwk": { | ||||||||
"alg": "ES256", | ||||||||
"kty": "EC", | ||||||||
"crv": "P-256", | ||||||||
"x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc", | ||||||||
"y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk" | ||||||||
} | ||||||||
} | ||||||||
} | ||||||||
~~~ | ||||||||
|
||||||||
An example of multiple assertions: | ||||||||
|
||||||||
~~~ | ||||||||
HTTP/1.1 200 Created | ||||||||
Content-Type: application/json | ||||||||
|
||||||||
{ | ||||||||
"status_assertion_responses": [ | ||||||||
$JWT_1, // Not revoked, boolean assertion | ||||||||
$JWT_2, // alg = none, suspended indicator | ||||||||
$JWT_3, // Preferences matrix assertion | ||||||||
] | ||||||||
} | ||||||||
~~~ | ||||||||
|
||||||||
# Security Considerations | ||||||||
|
||||||||
|
@@ -782,6 +903,13 @@ Status Assertions are based on a privacy-by-design approach, reflecting | |||||||
a deliberate effort to balance security and privacy needs in the | ||||||||
Digital Credential ecosystem. | ||||||||
|
||||||||
## Validity Reasons | ||||||||
|
||||||||
Depending by the scopes of how the detailed Status Assertions are implemented, these may disclose details about the Holder or subject that were not initially committed to during the original Credential issuance. This can potentially expose additional information that was not part of the original credentialing process. | ||||||||
Providing a reason that a Digital Credential is no longer valid can be essential to certain use cases, and unacceptable for others | ||||||||
For example, in a healthcare setting, a patient should not have medical reasons for a suspended credential disclosed in assertions of suspension. | ||||||||
However, in a supply chain context, a product suspension might benefit from additional information, such as batch or lot information. | ||||||||
|
||||||||
# IANA Considerations | ||||||||
|
||||||||
## JSON Web Token Claims Registration | ||||||||
|
@@ -802,6 +930,15 @@ IANA "JSON Web Token Claims" registry [IANA.JWT] established by {{RFC7519}}. | |||||||
* Change Controller: IETF | ||||||||
* Specification Document(s): [this specification](#status-assertion) | ||||||||
|
||||||||
<br/> | ||||||||
|
||||||||
* Claim Name: `credential_status_detail` | ||||||||
* Claim Description: New status information provided by the Issuer. | ||||||||
* Change Controller: IETF | ||||||||
* Specification Document(s): [this specification](#status-assertion) | ||||||||
|
||||||||
|
||||||||
|
||||||||
## Media Type Registration | ||||||||
|
||||||||
This section requests registration of the following media types [RFC2046] in | ||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply talking about PII doesn't cover all the cases you can screw up basically.