Hi Daniel,
Hi Denis,
a discussion on claims-based/biometric binding, probably what you're
hinting at,
I am not hinting at a discussion "on claims-based/biometric binding".
is out of the scope of this document, since we define neither
mechanisms nor rules for that.
This should be part of a discussion with a larger scope, like the
Security & Trust document in OIDF's DCP group.
RFC 3552 (Guidelines for Writing RFC Text on Security Considerations)
states in its Introduction section:
All RFCs are required by RFC 2223 to contain a Security
Considerations section. The purpose of this is both to encourage
document authors to consider security in their designs and to
inform the reader of relevant security issues.
Section 5 of RFC 3552 states:
5. Writing Security Considerations Sections
(...)
There should be a clear description of the kinds of threats on the
described protocol or technology. This should be approached as an
effort to perform "due diligence" in describing *all known or
foreseeable risks and threats *to potential implementers and users.
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
"Collaborative attacks against a Verifier" should be added to the
Security Considerations section.
Denis
-Daniel
Am 26.10.23 um 11:01 schrieb Denis:
Hi All,
Section 11.6. is about "Key Binding" which is indeed an important
security feature.
However, in the context of "selective disclosure" while this feature
is essential, it is insufficient.
Let us take an example: If a Token indicates that an individual has
the nationality X, in case of a collusion between two individuals
and when using two pieces of software specifically developed for that
purpose, an individual would be able to compute and transmit
a Token to another individual for the benefit of that other
individual in order to cheat a Verifier. This is a collusion between
two individuals.
The first individual may not have the knowledge of the private key
but since he has the use of the private key, he is in a position to sign
anything he wants. Since the Token does not include claims allowing
to uniquely identity the individual, "if he is not seen, he will not
be caught".
"Collaborative attacks against a Verifier" should be added to the
Security Considerations section.
There exist ways to counter collaborative attacks against a Verifier.
These ways should be mentioned in the core of the document.
Denis
Hi all,
this release of SD-JWT includes one important normative change,
which is a hash in the key binding JWT to ensure the integrity of
presentations. The second biggest change is that we restructured
some sections of the document to make it more readable.
As always, we're looking forward to discussing SD-JWT here on the
mailing list and in Prague.
-Daniel
This is the full changelog:
-06
* Added hash of Issuer-signed part and Disclosures in KB-JWT
* Fix minor issues in some examples
* Added IANA media type registration request for the JSON
Serialization
* More precise wording around storing artifacts with sensitive data
* The claim name _sd or ... must not be used in a disclosure.
* Added JWT claims registration requests to IANA
* Ensure claims that control validity are checked after decoding
payload
* Restructure sections around data formats and Example 1
* Update JSON Serialization to remove the kb_jwt member and allow
for the disclosures to be conveyed elsewhere
* Expand the Enveloping SD-JWTs section to also discuss enveloping
JSON serialized SD-JWTs
Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org:
Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.
Title: Selective Disclosure for JWTs (SD-JWT)
Authors: Daniel Fett
Kristina Yasuda
Brian Campbell
Name: draft-ietf-oauth-selective-disclosure-jwt-06.txt
Pages: 90
Dates: 2023-10-23
Abstract:
This specification defines a mechanism for selective disclosure of
individual elements of a JSON object used as the payload of a JSON
Web Signature (JWS) structure. It encompasses various applications,
including but not limited to the selective disclosure of JSON Web
Token (JWT) claims.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Please use my new email address:m...@danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Please use my new email address:m...@danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
