Carsten wrote:
(...) it is impractical for a wallet to make this kind of
judgement for each issued credential.
Carsten is correct : a wallet /which is an application /cannot make any
kind of judgement.
However a human-being, i.e., an End-user that has the control over an
Holder (application)
can make different kinds of judgments.
The major problem is that the End-User is not identified or considered
in the draft.
Section 10. Privacy Considerations indicates:
*The privacy principles of [ISO.29100] should be adhered to.*
but the document is ignoring the content of this ISO 29100.
In the draft, the reference to this ISO standard is "ISO/IEC 29100:2011".
However, this reference is incorrect as ISO/IEC 29100:2011 has been
withdrawn by ISO and replaced by ISO/IEC 29100:2024
ISO/IEC 29100:2011 is no more publicly available.
ISO 29100:2024 has recently been made publicly available by ISO free of
charge.
There is no direct link to a pdf document, as you need to acknowledge
the copyright conditions from ISO.
So ISO 29100:2024 is available using the following six steps:
1) You first go on the following page:
https://standards.iso.org/ittf/PubliclyAvailableStandards/
2) You search for the character string "29100",
3) You click on the line that has been found: Information technology
— Security techniques — Privacy framework
4) You agree with the ISO conditions :
You are about to download a document protected by copyright.
When you download (an) ISO publication(s) from this site, you
must accept the ISO Customer Licence Agreement (“Licence
Agreement”),
excluding clauses 2. Watermark, 5. Paper copies, and 6. Codes
and Graphical Symbols (and their Collections).
5) you get a zipped file of the document,
6) you need to unzip the file.
The reference to ISO 29100 should be updated in section 13.2.
Informative References
At the minimum, the "consent and choice " principle from ISO 29100:2024
- Information technology — Security techniques — Privacy framework
should be considered and mentioned in the draft. It would be worthwhile
to add privacy principles that apply to the Verifiers.
Paul wrote:
To me, SD-JWT includes a thourough privacy consideration section on
unlinkability which is way beyond what other IETF specifications
have done is looks sufficient to me.
I don't believe that the current draft sufficiently address privacy as
it it ignoring the presence of the End-user and the content of ISO 29100.
Privacy is first an End-user concern. The Holder should support the
choices made by the End-user (once the End-user will have been
sufficiently informed).
When the Holder is capable of proposing some choices, the End-user
should have the ability to approve one of these choices or to deny all
of them.
This is based on the principle of "Consent and choice" which is the
first of the eleven privacy principles listed on page 14 in clause 6.2.
Yes, the data flows between the three roles happen between applications,
but the data flows originating from a Holder
should only happen if the End-user has given his consent at some point
of time.
The root of the problem comes from the fact that the term "End-user" is
not present in the draft and is not illustrated on Figure 1:
SD-JWT Issuance and Presentation Flow*. *Figure 1 should be corrected as
follows :
*
+------------+*
*||*
*|Holder|<--- End-user*
*||*
*+------------+*
Once the End-Users will be introduced into the Figure as well as into
the draft, the definition of an Holder which currently is:
*Holder:An entity that received SD-JWTs from the Issuer and has control
over them.In the context of this document, the term may refer to the
actual user, the supporting hardware and software in their possession,
or both..*
would need to be modified so that the application can be dissociated
from the End-user that has the control over the Holder (application).
Afterwards, the document will be much more understandable.
I do know that this terminology problem originates from the VCDM 1.0
document from W3C which is making the same confusion.
VCDM 2.0 is a data model, it is not an Architecture document. The
document has forgotten that these exchanges happens because
they are normally done with the consent of the User (while some
exchanges could be done maliciously by the Holder without
the consent of the End-user ... but this is another story).
Denis
Standardization does not enable legal solutions – that`s job of
legislators but standardization shall recognize existing
standardization on records management which is affected here. Acc. to
ISO 15489, ISO 30301 (ISO Tc 46 Sc 11) the definition of retention
period is in responsibility of records manager and mostly not defined
in advance. Means your idea “The retention and disposal periods for
that information should be clearly defined, enforced, and communicated
to data subjects” won`t work
““Personal information gathered for a specific purpose should not be
used for other purposes without the person's consent.” àdecision by
records manager acc. ISO 15489, ISO 16175 and ISO 30301.
Long Story short: Technical requirements shall follow international
standards – this is what your idea Tom lack off
*Von:* Tom Jones <thomasclinganjo...@gmail.com>
*Gesendet:* Dienstag, 17. Dezember 2024 18:41
*An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
*Cc:* Tom Jones <pe...@acm.org>; Pierce Gorman
<pierce.gor...@numeracle.com>; IETF oauth WG <oauth@ietf.org>
*Betreff:* Re: [OAUTH-WG] Re: SD-JWT linkability
*Caution:* This email originated from outside of the organization.
Despite an upstream security check of attachments and links by
Microsoft Defender for Office, a residual risk always remains. Only
open attachments and links from known and trusted senders.
Legal requirements can only be adjudicated by legal means. The common
approach in standards developments should be to enable a legal
solution not to mandate it.
thx ..Tom (mobile)
On Mon, Dec 16, 2024, 11:14 PM Steffen Schwalm
<Steffen.Schwalm@msg.group> wrote:
In > 80% of use cases the retention period is not defined by law
but defined by records manager after receiving the information
from holder. So data retention won`t work. For those thinking
about GDPR: Yes possible within GDPR too as GDPR does not require
definition retention during collection of PII. Means only strong
human-centric ID of verifier and purpose possible
“Personal information gathered for a specific purpose should not
be used for other purposes without the person's consent.” àdoes
this mean an administration is not allowed to give information
about location collected for one purpose to the police for
another? This would legally not work
*Von:* Tom Jones <thomasclinganjo...@gmail.com>
*Gesendet:* Dienstag, 17. Dezember 2024 02:26
*An:* Pierce Gorman <pierce.gor...@numeracle.com>
*Cc:* pe...@acm.org; IETF oauth WG <oauth@ietf.org>
*Betreff:* [OAUTH-WG] Re: SD-JWT linkability
*Caution:* This email originated from outside of the organization.
Despite an upstream security check of attachments and links by
Microsoft Defender for Office, a residual risk always remains.
Only open attachments and links from known and trusted senders.
I could have been more clear. If a verifier is asking for
information, it must include strong human-centric ID of verifier,
data retention and purpose. That is not currently possible with
the VP. This makes the OID4VP an unethical means to request
information. See the following:
https://www.acm.org/code-of-ethics
Only the minimum amount of personal information necessary should
be collected in a system. The retention and disposal periods for
that information should be clearly defined, enforced, and
communicated to data subjects. Personal information gathered for a
specific purpose should not be used for other purposes without the
person's consent.
Clearly information holders can do what they want with their own data.
Peace ..tom jones
On Mon, Dec 16, 2024 at 11:22 AM Pierce Gorman
<pierce.gor...@numeracle.com> wrote:
I think I disagree. I assume an SD-JWT in a VP could be
volunteered by a Holder initiating a transaction. i.e., the
relying party Verifier didn’t request the VP.
The example I would give is an enterprise making a phone call and
using SIP INVITE method Identity header to carry an SD-JWT VP.
In the US, the TRACED Act law and several FCC mandates require
voice calls in the Public Switched Telephone Network (PSTN) to be
authenticated using information contained in a JWT.
The basic type of JWT required is defined in RFC 8225 “PASSporT:
Personal Assertion Token” and is carried in the SIP INVITE method
Identity header.
There is also an I-D in the IETF STIR working group which proposes
use of an SD-JWT: Verified STI Persona (aka VESPER).
I assume the VP could be encoded by value in the SIP Identity JWT
or could be passed via a DID document reference (in theory).
Pierce
CONFIDENTIAL
*From:*Tom Jones <thomasclinganjo...@gmail.com>
*Sent:* Monday, December 16, 2024 12:50 PM
*To:* Watson Ladd <watsonbl...@gmail.com>
*Cc:* IETF oauth WG <oauth@ietf.org>
*Subject:* [OAUTH-WG] Re: SD-JWT linkability
You don't often get email from thomasclinganjo...@gmail.com. Learn
why this is important <https://aka.ms/LearnAboutSenderIdentification>
*EXTERNAL EMAIL*
The entire premise of SD-JWT in a VP transaction is basically
fraudulent as there is not sufficient information in the VP to
allow the user to make an informed consent decision. It gives the
illusion of user control without the ability to deliver on the
promise. For this proposal to have any value to the user it must
be part of a transaction that tells the user agent (wallet) who is
asking for the data and what the purpose of the request is. Absent
that, this give the impression of user control of release of data
without the fact.
BTW - the idea of dealing with the UX of the transaction is
admirable, but there are no UX people involved in the discussion.
Peace ..tom jones
On Wed, Dec 11, 2024 at 5:01 PM Watson Ladd
<watsonbl...@gmail.com> wrote:
Dear all,
I'd like to propose the following edit to resolve the concerns I have
around endorsing dangerous applications of SD-JWT:
Delete last two lines of
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/451/files
in 1338 and 1339
Add new paragraph right before the end of the section.
"When disclosures include information easily understood to be
identifying, users intuitive view of what they are revealing largely
matches the underlying technical reality. In cases where the
information being disclosed is not identifying, SD-JWT
MUST NOT be used as this confusion leads to users making the wrong
choices. Applications cannot assume Verifiers behave properly (RFC
3514) and MUST analyze the consequences for such linkage with each
credential that could be used."
I think this agrees with many of the comments made about my initially
stronger edit, while addressing the core danger.
Also, it seems this section only really treats issuer/verifier despite
promising more. Do we need to rework it?
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
