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 to oauth-le...@ietf.org
