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<mailto: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<mailto:thomasclinganjo...@gmail.com>> Gesendet: Dienstag, 17. Dezember 2024 02:26 An: Pierce Gorman <pierce.gor...@numeracle.com<mailto:pierce.gor...@numeracle.com>> Cc: pe...@acm.org<mailto:pe...@acm.org>; IETF oauth WG <oauth@ietf.org<mailto: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<mailto: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<mailto:thomasclinganjo...@gmail.com>> Sent: Monday, December 16, 2024 12:50 PM To: Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>> Cc: IETF oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: [OAUTH-WG] Re: SD-JWT linkability You don't often get email from thomasclinganjo...@gmail.com<mailto: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<mailto: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<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
