[OAUTH-WG] Re: oauth-selective-disclosure-jwt Pull 451 is insufficient

[Tom Jones]

I completely agree that education of users is not an answer to any security
question.

Be the change you want to see in the world ..tom


On Thu, Aug 22, 2024 at 10:08 AM Watson Ladd  wrote:

> Hello,
>
> I would like to point out that the issuer verifier problem still
> remains open, even given the text in 11.
>
> The text is directionally wrong. It discusses how the issuer and
> verifier must be trusted, not what they can do together, and than only
> says that deployers must be aware and educate users. There's nothing
> actionable here, and user education doesn't work. Users cannot make
> security decisions of this nature, as we know from decades and decades
> of experience.
>
> Can we please get text that informs our readers what the issue is and
> what the risks are?
>
> 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

[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones]

I really do not understand most of Mike's objections.
If key reuse were such a problem then TLS keys should be used for nothing
but TLS. He didn't complain about that.
The original use of PKI was application level protection. TLS came later.
I am no fan of X.509. It is ubiquitous right now.
Peace ..tom jones


On Mon, Sep 16, 2024 at 12:56 PM Michael Jones 
wrote:

> I regret to have to report that the issues that I believe resulted in the
> first call for adoption failing, despite being discussed on-list and at
> IETF 120, have not been addressed in the specification
> <https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.html>.  I did
> have a productive conversation with Richard in Vancouver, which resulting
> in him mentioning some of the problems in his presentation
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>.
> Here are the problems that have not been addressed since the first call for
> adoption:
>
>
>
>1. *Application-level use of PKI trust chains.*  As I wrote in my
>response to the first call for adoption
><https://mailarchive.ietf.org/arch/msg/oauth/rPPI9E8fwN1NiMM1TkaQUfFYEDI/>,
>“Other than for TLS certificates, the OAuth and JOSE specs generally
>steer clear of dependence upon X.509 certificates.  Especially for a spec
>focused on JWK Sets, it’s odd to require an X.509 certificate to secure
>them.”  This problem is acknowledged in Issue 1 of Slide 7 of Richard’s
>presentation
>
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>.
>As I also wrote
><https://mailarchive.ietf.org/arch/msg/oauth/zvIsbxHTFC4YXozOgOfQutR6GN8/>,
>“application-level X.509 … is an anachronism that OAuth and JOSE have
>moved away from”.
>2. *Reuse of keys intended for one purpose for a different purpose.*
>PIKA uses WebPKI keys for signing things that are not Web resources.  Key
>reuse is not a good security practice.  This problem is acknowledged in
>Issue 2 of Slide 7 of Richard’s presentation
>
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>
>.
>3. *Authorities with paths not secured.*  In OAuth, authorities such
>as issuers can have a path component in their URL.  But the spec says “The
>contents of this field *MUST* represent a certificate chain that
>authenticates the domain name in the iss field” – meaning that the path
>component of the issuer is not secured.
>4. *Odd hybrid of JWKs and X.509.*  The spec uses both JSON Web Keys
>and X.509 certificates in the trust evaluation, which is an odd intermixing
>of technologies with overlapping purposes.  Architecturally, it would be
>cleaner to go all in on one or the other.  This is evident in Slide 5 of 
> Richard’s
>presentation
>
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>
>.
>5. *Upgrade path not defined.*  As Slide 7 of Richard’s presentation
>
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>
>says, “Need to make sure that systems using PIKA have a clear
>upgrade/interop path to alternatives to application-level certificates
>(e.g., OpenID Federation)”.  This is a point that I know John Bradley made
>to Richard in person in Vancouver.  This problem is not addressed in the
>specification.
>
>
>
> I’m also personally uncomfortable with the *direction of travel* embraced
> by this specification.  For over a decade, we’ve been consciously working
> to move OAuth away from X.509 and towards JOSE and this specification goes
> in the opposite direction.
>
>
>
> As documented above, these problems were discussed and acknowledged.
> Therefore, it’s disappointing to me that the updated draft didn’t address
> these previously identified issues.
>
>
>
> Therefore, I believe this specification should not be adopted, as the
> problems that caused it to not be previously adopted have not been
> addressed.
>
>
>
> Sincerely,
>
> -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Tuesday, September 3, 2024 3:47 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Call for adoption - PIKA
>
>
>
> All,
>
> As per the discussion in Vancouver, this is a call for adoption for the *Proof
> of Issuer Key Authority (PIKA) *draft:
> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by *Sep 17th*.
>
> Regards,
>  Rifaat & Hannes
> ___
> 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

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Tom Jones]

What, exactly is json encoding? It sounds like a python or java method.
Afaik json can be encoded in utf 8 16 or 32. But form encoding is limited
to ascii or even to base64url
.. Is that the point. Will GNAP specify one encoding?

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 12:29 PM Justin Richer  wrote:

> In the ten years since OAuth started, we’ve seen a huge shift away from
> form encoding to JSON encoding for sending data to a server. And yet, OAuth
> is stuck with form encoding. So I thought, why can’t we change that?
>
> I put together a quick proposal for how this would work.
>
> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html
>
> The basic idea is that you take the map of form inputs and make it into a
> JSON object. For some fields, like scope and authorization_details, you can
> define a JSON-specific encoding to make use of object and array structures
> native to JSON. You also don’t have to url-encode values inside the JSON
> strings.
>
> Caveat, I haven’t tried implementing this yet, but I think it’s not likely
> to be that difficult for either the client or server side of things. At
> worst it seems like it’d be a pretty simple middleware function.
> Functionality can be detected at the AS by the content negotiation in HTTP
> (client sends content-type of JSON), and can be advertised as an option in
> the metadata (or in an OPTIONS call to the token endpoint, to be more
> HTTP-friendly).
>
>  — Justin
> ___
> 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

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Tom Jones]

ahh - thx - so that explains why RFC 6749 OAuth 2.0 is ambiguous on the
topic. I suspect that means that GNAP will take a dependency on 8259,
Peace ..tom


On Mon, Jul 13, 2020 at 8:34 AM Carsten Bormann  wrote:

> On 2020-07-13, at 17:19, Tom Jones  wrote:
> >
> > What, exactly is json encoding?
>
> JSON is defined in RFC 8259.
> The term “encoding” is ambiguous here, it could be used for the encoding
> of a JSON text (which employs UTF-8) or the representation of an
> application data model using the JSON generic data model.
>
> > It sounds like a python or java method.
>
> Many languages and platforms support JSON.
>
> > Afaik json can be encoded in utf 8 16 or 32.
>
> Early definitions of JSON said so, even though that practically never
> happened in interchange.  RFC 8259 supports UTF-8 encoding only.
>
> Grüße, Carsten
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication

[Tom Jones]

I have concerns, similar to Orie's, about assertions. Like Orie, I would
like to see something like this approved, but it must be secure. The
following is the part of the draft that concerns me.

   Therefore, the client generates a key (Client Instance Key) and
(platform specific) attestations to prove its authenticity, integrity
and security to the client backend (step 1)


First - I assume this is a web client, is that correct?  It is not
stated anywhere I looked.


So I have been following an effort in blink-dev to have the browser API
include assertions of the sort I believe are of interest here. That is
generated by the DOM.
https://rupertbenwiser.github.io/Web-Environment-Integrity/
My concern is that there is a large amount of push back to seeing this
approved. If approved it would allow what you ask. If not it is unclear to
me how you would achieve the "(platform specific) attestations to prove its
authenticity".  If you have more detail on how this might work on android
and iphone, I would like to hear it.

In the mean-time i am working to get the above Web-Environment-Integrity/
change approved.  If you would like to help make that possible let me know
that you would put your name to the effort.

__
Of course, if this is a native client, we can use other methods that are
available today to proof it.

..tom


On Thu, Jul 20, 2023 at 11:57 AM Tobias Looker  wrote:

> Hi All,
>
>
>
> Paul and I would like to draw attention to a new draft we have submitted
> titled “OAuth 2.0 Attestation-Based Client Authentication” which will be
> presented at the up and coming IETF 117 meeting during the Friday meeting
> slot. This draft is related to the group of drafts on verifiable
> credentials that will be presented during this meeting slot. Specifically
> this draft is intended to address but not limited to eIDAS 2.0 usage of
> OpenID4VCI which requires wallet applications to be strongly authenticated
> via attestations.
>
>
>
> The current abstract of the draft is as follows:
>
>
>
> “This specification defines a new method of client authentication for
> OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This
> new method enables client deployments that are traditionally viewed as
> public clients to be able to authenticate with the authorization server
> through an attestation based authentication scheme.”
>
>
>
> Link to the current editors copy =>
> https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/
>
>
> Link to the specification repository =>
> https://github.com/vcstuff/draft-looker-oauth-attestation-based-client-auth
>
>
>
> Thanks,
>
> [image: MATTR website] 
>
>
>
> *Tobias Looker*
>
> MATTR
>
> +64 273 780 461
> tobias.looker@mattr.global 
>
> [image: MATTR website] 
>
> [image: MATTR on LinkedIn] 
>
> [image: MATTR on Twitter] 
>
> [image: MATTR on Github] 
>
>
> This communication, including any attachments, is confidential. If you are
> not the intended recipient, you should not read it – please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
> ___
> 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

Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication

[Tom Jones]

You really need to make it clear that these are native not web.

Please point me to demo.

thx ..Tom (mobile)

On Wed, Jul 26, 2023, 2:32 PM Paul Bastian  wrote:

> Hello Tom,
> The client attestation draft does not make any suggestions on the
> architecture but gives a general purpose mechanism how to authenticate a
> client in OAuth using an attestation.
> The primary/first use case for this is public clients for high assurance
> credentials with OpenID4VCI in eIDAS, focusing on mobile apps and not on
> web wallets. For this use case we already developed a demonstrator and
> presented this at last IIW.
> How the authorisation server trusts the attestation of the client
> backend(the attestation service) is out of scope of this specification, but
> will ultimately be solved by prearranged trust relations or trust
> frameworks with trust lists.
> Best regards, Paul
> ___
> 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

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Tom Jones]

Right Philippe -  there really is no way to create a secure client as a web
app.  You would need access to the trusted execution environment, which is
not available.

..tom


On Sat, Aug 26, 2023 at 5:21 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> My responses inline.
>
>
> Hi everyone,
>
> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
> further explains that it "details the security considerations and best
> practices that must be taken into account when developing browser-based
> applications that use OAuth 2.0.".
>
> As such, detailing security considerations is important. I share the point
> of view that basing web applications on proven concepts is important. The
> approaches detailed in the document have all their advantages
> and disadvantages.
>
>
> We have discussed the topic of browser-based apps in depth at the OAuth
> Security Workshop last week. I am also working with Aaron Parecki on
> updating the specification to more accurately reflect these advantages and
> disadvantages. Updates will go out in the coming days/weeks, so we more
> than welcome concrete feedback on the content there.
>
> There are 2 main approaches to browser-based applications security. One of
> them is to store security credentials at the frontend. The other one is to
> use cookies and a BFF. Though common practice, there is nothing
> fundamentally more secure about them in a demonstrable way. Different
> approaches, different characteristics and security assumptions. Nobody can
> prove that either approach is better, just that there are different
> concerns.
>
> Handling security in BFFs relies on cookies that cannot be read by the
> javascript application. This mechanism provides some reliable protection
> about the cookie itself that is used as a kind of credential to access
> confidential web resources. It obviously demands some additional layers in
> the flow (proxy or light server). You also need a mechanism to share
> session information, either at the server side, or for example by having
> the cookie itself hold that information. A bigger concern to me is that you
> basically give up standard mechanisms for securing the flow between the
> frontend and the backend: the security between the two is a custom solution
> (based on cookies, in a specific, custom way, this part being in no way
> OAuth or standard). This solves the problem by not using OAuth at all in
> the browser part of the application, basically making the client
> application purely backend. However, the fact that browser-based
> applications cannot be secured with OAuth isn't universally true, and
> strongly depends on one's definition of "secure", and basically comes down
> to what the security issue is.
>
>
> The updated specification will clearly outline the security considerations
> when making the browser-based application a public OAuth client.
>
> *The main problem with a browser-only client is that the attacker with
> control over the client has the ability to run a silent Authorization Code
> flow, which provides them with an independent set of tokens.* These
> tokens give the attacker long-term and unrestricted access in the name of
> the user. A BFF-based architecture does not suffer from this issue, since
> the OAuth client is a confidential client. Regardless of one’s definition
> of “secure”, this is a clear difference on the achievable level of
> security.
>
> Of course, as stated multiple times before, the use of a BFF does not
> eliminate the presence of the malicious JS, nor does it solve all abuse
> scenarios.
>
>
>
> Storing tokens at the frontend has advantages: it solves my concern above
> about a standard based flow between the frontend and the backend.
>
>
> The use of cookies is a core building block of the web, and is quite
> standard.
>
> It's simpler from an operational point of view. And it's been used in the
> wild for ages.
>
>
> Anyone using a browser-only client should be informed about the clear and
> significant dangers of this approach, which the updated specification will
> do.
>
>
> Both flows have been compromised numerous times. This doesn't mean they
> are not right by design, but that the specific security concerns have to be
> addressed.
>
>
> If you have specific security concerns about a BFF, I’d suggest raising
> them. Until now, I have only seen arguments that highlight the additional
> effort it takes to implement a BFF, but nothing to undermine its security.
> Plenty of highly sensitive applications in the healthcare and financial
> industry opt for a BFF for its improved security properties and consider
> this trade-off to be favorable.
>
>
> Now, the concerns we are really discussing is, what happens in case of XSS
> or any form of malicious javascript.
>
> In this case, for all known flows, session riding is the first real issue.
> Whether the injected code calls protected web resources through the BFF or
> using the stored tokens, is irrelevant: the 

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Tom Jones]

The security reason for exclusion of error codes and other information is
that the data helps the attacker subvert the app. I continue my attempt to
avoid helping the attacker.

thx ..Tom (mobile)

On Sat, Aug 26, 2023, 7:58 AM Dick Hardt  wrote:

> Jaimandeep: Do I understand your objection to adoption is that providing a
> resource discovery endpoint increases the attack surface as an
> attacker gains knowledge about the resource?
>
> If I understand that correctly, then you are suggesting security through
> obscurity.
>
> As mentioned by Aaron, there is no requirement for a resource to support
> the resource metadata, and the metadata itself could be protected.
>
> Practically though, I believe the argument that security is improved by
> not having a resource discovery endpoint is false. Most resources have
> publicly available documentation which will contain the same information,
> and while the docs are not necessarily machine readable, LLMs can make it
> pretty accessible.
>
> Even if you wanted to keep it secret, if applications that use the
> resource are readily available, how the applications interact with the
> resource can be discerned through reverse engineering.
> I think that a security consideration calling out that a malicious actor
> more readily has access to the protected resource metadata is an adequate
> response.
>
> For my use case, the protected resource metadata is required for the
> functionality I plan to implement. The AS has no prior knowledge about the
> protected resource, and when a request is made, the AS learns about the PR
> and presents the user with an experience based on the metadata for the user
> to make a decision to grant access.
>
> /Dick
>
>
>
> On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Hi Aaron,
>>
>> Thx for your suggestions. I have reviewed the recordings and I would
>> suggest following:
>>
>> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem
>> authorization server (step 1) and protected resource server (step 2) may
>> appear independent, but from systems perspective there is a linear
>> dependency between them. Directly engaging with step 2, even in a limited
>> capacity, threatens the established sequence and poses substantial security
>> and architectural implications.
>>
>> 2. Information Disclosure: Say I have my HIPPA record stored on a
>> protected resource server, I don't want any app to even know that I have
>> such a resource available with a protected resource server in the first
>> place. The concept of exposing the mere existence of such data raises a
>> glaring concern. Looking at Google, it has a fine-grained authorization
>> strategy that meticulously limits access for its RESTRICTED scopes only to
>> apps that meet certain security benchmarks. Once, the malicious apps come
>> to know of the prized data at the resource server, it will lead to targeted
>> phishing attacks, as was highlighted during the 117 meeting, underscoring
>> the fragility of this approach.
>>
>> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to
>> go down this path, there is a definite need to mitigate the perils of
>> overexposure. Instead we can look at gradation strategy, wherein the scopes
>> could be categorized into levels, spanning from generic (Level 0) to
>> tightly controlled (Level 5) access. There is no requirement of
>> secondary URI in this appch. For instance, the sensitive scopes like level
>> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
>> need to divulge if a particular resource is present or not and not even the
>> address of the authorization server.
>>
>> Thanks
>> Jaimandeep Singh
>>
>>
>> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki > 40parecki@dmarc.ietf.org> wrote:
>>
>>> Hi Jaimandeep,
>>>
>>> As with many OAuth extensions, this is not obligatory to implement
>>> unless you need the functionality it provides. Many of the concerns you
>>> mention are referenced in the security considerations section of the draft
>>> already, and we would of course be happy to further expand that section as
>>> appropriate.
>>>
>>> As we presented during the last two IETF meetings, there are many use
>>> cases that would benefit from this draft that currently don't have an
>>> interoperable solution. I would suggest you review those presentation
>>> recordings so better understand the use cases.
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh >> 40nfsu.ac...@dmarc.ietf.org> wrote:
>>>
 I do not support the adoption because of following:

 1. Increased Attack Surface and Information Disclosure: The proposed
 draft inherently expands the attack surface by allowing the retrieval of
 detailed information about the protected resources held with a
 particular resource server, as outlined in section 3.1. We are
 inadvertently exposing the resources supported by the protected resou

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Tom Jones]

You can write your code as strong as you wish. You cannot determine if the
code running in the computer is that code running unaltered. ..tom


On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros  wrote:

> Thanks for taking the time to respond and for the constructive feedback.
>
> Still, there is some initial incorrect point that makes the rest of the
> discussion complicated, and partly wrong.
>
> Specifically, §6.4.2.1 says this: *The service worker MUST NOT transmit
> tokens, authorization codes or PKCE code verifier to the frontend
> application.*
>
> Wording should be refined, but the idea is that the service worker is
> to actually restrict authorization codes from even reaching the frontend.
> Of course, easier said than done, but that part happens to be quite easy to
> implement.
>
> This has further impact on much of the other statements:
> *> The main problem with a browser-only client is that the attacker with
> control over the client has the ability to run a silent Authorization Code
> flow, which provides them with an independent set of tokens*
> [...]
> *> **The security differences between a BFF and a browser-only app are
> not about token storage, but about the attacker being able to run a new
> flow to obtain tokens.*
> [...]
> *> Again, the security benefits of a BFF are not about stoken storage.
> Even if you find the perfect storage solution for non-extractable tokens in
> the browser, an attacker still controls the client application and can
> simply request a new set of tokens. *
>
> Truth is: no, you can't start a new authentication flow and get the
> authorization code back in the main thread. I'm talking about the
> redirection scenario, which I'm the most familiar with, but it would
> probably apply to the "message" one as well (which is new to me and seems
> to be ashtoningly legit due to vague "for example" wording in the OAuth2
> spec :-) ).
>
> The service worker, according to
> https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description
> , just intercepts the authorization code, gets a token, and never sends it
> back to the main code.
>
> But don't trust me on my words: what about demonstrating our claims with
> actual code, and as such create a shorter, simpler, but more constructive
> discussion?
>
> The demonstration in its current form would not lead to a successful
> compromise of a good implementation of access tokens handled by a service
> worker.
>
> Yannick
>
>
> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> a écrit :
>
>> My responses inline.
>>
>>
>> Hi everyone,
>>
>> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
>> further explains that it "details the security considerations and best
>> practices that must be taken into account when developing browser-based
>> applications that use OAuth 2.0.".
>>
>> As such, detailing security considerations is important. I share the
>> point of view that basing web applications on proven concepts is important.
>> The approaches detailed in the document have all their advantages
>> and disadvantages.
>>
>>
>> We have discussed the topic of browser-based apps in depth at the OAuth
>> Security Workshop last week. I am also working with Aaron Parecki on
>> updating the specification to more accurately reflect these advantages and
>> disadvantages. Updates will go out in the coming days/weeks, so we more
>> than welcome concrete feedback on the content there.
>>
>> There are 2 main approaches to browser-based applications security. One
>> of them is to store security credentials at the frontend. The other one is
>> to use cookies and a BFF. Though common practice, there is nothing
>> fundamentally more secure about them in a demonstrable way. Different
>> approaches, different characteristics and security assumptions. Nobody can
>> prove that either approach is better, just that there are different
>> concerns.
>>
>> Handling security in BFFs relies on cookies that cannot be read by the
>> javascript application. This mechanism provides some reliable protection
>> about the cookie itself that is used as a kind of credential to access
>> confidential web resources. It obviously demands some additional layers in
>> the flow (proxy or light server). You also need a mechanism to share
>> session information, either at the server side, or for example by having
>> the cookie itself hold that information. A bigger concern to me is that you
>> basically give up standard mechanisms for securing the flow between the
>> frontend and the backend: the security between the two is a custom solution
>> (based on cookies, in a specific, custom way, this part being in no way
>> OAuth or standard). This solves the problem by not using OAuth at all in
>> the browser part of the application, basically making the client
>> application purely backend. However, the fact that browser-based
>> applications cannot be secured with OAuth isn't universally tr

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Tom Jones]

Something is deeply flawed about this thread. Consider that the following
quote from Steiner talks about information in the client as though the
client were actually the client is the resource owner. But the resource
owner should view the client as just another attacker. Somewhere the
interest of the data owner should be considered as we know that any
standard creates a race to the bottom, to the cheapest solution that can
claim compliance.

The level of security you require for any client is often a reflection of
the sensitivity of the information that the API exposes.

thx ..Tom (mobile)

On Mon, Aug 28, 2023, 2:36 AM Steinar Noem  wrote:

> I think this is a great discussion, and it seems to me that Yannicks last
> comment is basically what Phillippe is trying to point out..
> I just wanted to remind the authors about a couple of things that we
> briefly discussed during OSW in London.
>
> Although it might not be directly relevant for this discussion I do think
> that it might be a good idea that the spec mentions that:
>
>- The level of security you require for any client is often a
>reflection of the sensitivity of the information that the API exposes. You
>will have different requirements for confidential information than for open
>data. An example of a similar recommendation can be found in the HTTP
>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>- In my domain it is most often the owner of the API (the data
>controller) who defines and approves the level of security which it finds
>to fit their responsibilities (e.g. legal obligations) - although in some
>cases it might be both the data provider and the data consumer. Meaning -
>this BCP might be equally important for the API-owner as it is to the
>client developer.
>- I think this discussion shows that any mitigation on the browser
>side will only raise the bar for the attacker, and can never be a fully
>effective countermeasure. I think this point could be even more clearly
>stated early in the spec, and that both the API-owner or client owner
>should be aware of this risk, and select their appropriate choice of
>security measures based on a risk assessment. In some cases their
>conclusion might be that a browser based app is not secure enough for
>their responsibilities.
>
>
> S
>
> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>
>> Yes, but this is true for all flows. Web applications are dangerous.
>> Applications handling user input are dangerous too.
>>
>> Le dim. 27 août 2023, 17:46, Tom Jones  a
>> écrit :
>>
>>> You can write your code as strong as you wish. You cannot determine if
>>> the code running in the computer is that code running unaltered. ..tom
>>>
>>>
>>> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros 
>>> wrote:
>>>
>>>> Thanks for taking the time to respond and for the constructive feedback.
>>>>
>>>> Still, there is some initial incorrect point that makes the rest of the
>>>> discussion complicated, and partly wrong.
>>>>
>>>> Specifically, §6.4.2.1 says this: *The service worker MUST NOT
>>>> transmit tokens, authorization codes or PKCE code verifier to the frontend
>>>> application.*
>>>>
>>>> Wording should be refined, but the idea is that the service worker is
>>>> to actually restrict authorization codes from even reaching the frontend.
>>>> Of course, easier said than done, but that part happens to be quite easy to
>>>> implement.
>>>>
>>>> This has further impact on much of the other statements:
>>>> *> The main problem with a browser-only client is that the attacker
>>>> with control over the client has the ability to run a silent Authorization
>>>> Code flow, which provides them with an independent set of tokens*
>>>> [...]
>>>> *> **The security differences between a BFF and a browser-only app are
>>>> not about token storage, but about the attacker being able to run a new
>>>> flow to obtain tokens.*
>>>> [...]
>>>> *> Again, the security benefits of a BFF are not about stoken storage.
>>>> Even if you find the perfect storage solution for non-extractable tokens in
>>>> the browser, an attacker still controls the client application and can
>>>> simply request a new set of tokens. *
>>>>
>>>> Truth is: no, you can't start a new authentication flow and get the
>>>> authorization code back in the main thread. I'm talking about the
>>>

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Tom Jones]

+1 Denis.

I cannot understand why OAuth is used in this user (or many others in
development) as there is no authorization involved!

The verifier asks the user (wallet) for data (perhaps with some back and
forth) the user (wallet) supplies the data or not with consent to the
conditions supplied by the verifier.There is no separate RO or
authorization path.

Starting with OAuth in these cases adds a level of complexity that is
wholly unnecessary.

..tom


On Sat, Sep 9, 2023 at 6:44 AM Denis  wrote:

> Historically, the OAuth WG has been using a model including five
> components: the user, the Client, the AS, the RO and the RS.
>
> The model applicable in the context of the "three part model (issuer,
> holder, verifier)" is rather different since there is no AS, nor RO.
> An AS should not be confused with an Issuer. An Issuer has no relationship
> with a verifier.
>
> In the "three part model", a Credential is issued by an Issuer to an
> holder who may then derive himself from it one or more Verifiable
> Presentations
> without any call-back to the Issuer. The holder may then present to a RS
> one or more Verifiable Presentations derived from Credentials issued
> by the same or different Issuers. It is implicit that the "three part
> model" shall support selective disclosure of the holder's attributes.
>
> The "three part model (issuer, holder, verifier)" involves more entities /
> components: the user, the TEE (Trusted Execution Environment)
> supported by the smart phone or tablet manufacturer, Trusted Applications
> (TAs) placed into the TEE, the providers of these Trusted Applications
> (TAs)
> and the RichOS supported by the smart phone or tablet. Security and
> privacy concerns can only be achieved while considering the whole chain.
>
> The protocols between an holder and a verifier are rather different from
> those defined din OAuth, since in many cases they support Zero-Knowledge
> proofs (ZKPs).
>
> Before designing an architecture, it is important to raise the following
> questions:
>
>- Is it desirable to support linkability between verifiers and/or
>unlinkability between verifiers ?
>- How to bind a Verifiable Presentation to its legitimate holder while
>also supporting the unlinkability property between verifiers ?
>
> IMO, bridging the architectural narrative used in the core OAuth framework
> (AS, RS, RO) and three part model (issuer, holder, verifier) is not
> desirable.
> This would add confusion. Extending the OAuth charter to address the "three
> part model" is not desirable.
>
> Some committees and foundations are already addressing this topic, e.g.,
> W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform
> (for the TEE).
>
> The key question is: what the IETF should do (*or not do)* in this area ?
>
> A BoF should be opened to continue this discussion.
>
> Denis
>
> Thanks for kicking off the conversation!
>
> Inline:
>
> On Fri, Sep 8, 2023 at 2:08 PM Roman Danyliw  wrote:
>
>> Hi!
>>
>> We've observed growing energy around JWT, selective disclosure and VC
>> related topics in the WG in recent meetings.  We spent almost all of the
>> third OAuth meeting at IETF 117 on related topics.  The initial SD-JWT
>> (draft-ietf-oauth-selective-disclosure-jwt) has been followed up with
>> SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc).  There is also work like
>> draft-looker-oauth-jwt-cwt-status-list being proposed.
>>
>> As promised at IETF 117, we would like to start a conversation about the
>> direction the WG would like to take at a strategic level rather than
>> continuing to deal this topic in one document increments of additional
>> scope.
>>
>> ** What's the body of work around SD/JWT/VC that should be done and how
>> much work will that be?  What needs to be done first?  What unknown about
>> the direction and needed tasks?
>>
>>
> There are building blocks that "look like VC" but are actually vanilla JWT
> / relevant outside the 3 party model. I would recommend keeping them at
> OAuth (status list cwt is an example of this IMO).
>
> It's possible that a document at OAuth recognizing the data model elements
> of the 3 party model (iss, sub, cnf, kid, etc) might help enable documents
> outside of OAuth to better defer to OAuth for "moving tokens, or leveraging
> successful protocols"... this could help reduce the data model reinvention
> everywhere else, and it could drive the common understanding of registered
> claim names to be interpreted consistently across JWT / CWT (and their SD
> friends).
>
>
> ** For whatever that work might be, how should the OAuth charter evolve to
>> support the work?
>>
>>
> I don't know, but I am happy to help : )
>
> One thing that seems worth unpacking is why DCP at OIDF is leaving the
> OIDC part behind (paraphrasing, kristina probably has a better take):
> https://openid.net/wg/digital-credentials-protocols/
>
> Are there things DCP might need from OAuth WG, how might the charter align
> to that work?
>
>
>> ** Is there work 

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Tom Jones]

The problem is that we need a 2 party, off-line model for the world of
mobile devices.
that should not depend on OAuth.

..tom


On Mon, Sep 11, 2023 at 8:22 AM Orie Steele 
wrote:

> As far as I know, OpenID and DIF both use OAuth for these cases (the 3
> party model).
>
> W3C focuses only on the data model (in JSON-LD and RDF) and lacks
> the expertise to focus on the other parts (including security, and
> transport considerations IMO.)
>
> GlobalPlatform and others are related to the area by the concept of
> attestation, which is related to gaining higher confidence in the OAuth
> roles (Client, Resource Server, wallet / credential issuer, etc...)
>
> Regarding a BoF for this topic, as opposed to extending the OAuth charter,
> you might be interested in: https://mailarchive.ietf.org/arch/browse/spice
>
> Regardless of where the "3 party model" lands at IETF, I think there
> should be coordination with JOSE, COSE, OAUTH, given their existing use in
> this ecosystem...
>
> But that does not necessarily mean charter changes for OAuth, it could be
> as simple as cross posting and seeking review where it makes sense to do so.
>
> Maybe a different way of gaining clarity on the same topic... If OAUTH
> were to recharter, what would it include / exclude... (ignoring the 3 party
> model for a second)... would attestaton be in scope?
>
> Regards,
>
> OS
>
>
> On Sat, Sep 9, 2023 at 12:57 PM Tom Jones 
> wrote:
>
>> +1 Denis.
>>
>> I cannot understand why OAuth is used in this user (or many others in
>> development) as there is no authorization involved!
>>
>> The verifier asks the user (wallet) for data (perhaps with some back and
>> forth) the user (wallet) supplies the data or not with consent to the
>> conditions supplied by the verifier.There is no separate RO or
>> authorization path.
>>
>> Starting with OAuth in these cases adds a level of complexity that is
>> wholly unnecessary.
>>
>> ..tom
>>
>>
>> On Sat, Sep 9, 2023 at 6:44 AM Denis  wrote:
>>
>>> Historically, the OAuth WG has been using a model including five
>>> components: the user, the Client, the AS, the RO and the RS.
>>>
>>> The model applicable in the context of the "three part model (issuer,
>>> holder, verifier)" is rather different since there is no AS, nor RO.
>>> An AS should not be confused with an Issuer. An Issuer has no
>>> relationship with a verifier.
>>>
>>> In the "three part model", a Credential is issued by an Issuer to an
>>> holder who may then derive himself from it one or more Verifiable
>>> Presentations
>>> without any call-back to the Issuer. The holder may then present to a RS
>>> one or more Verifiable Presentations derived from Credentials issued
>>> by the same or different Issuers. It is implicit that the "three part
>>> model" shall support selective disclosure of the holder's attributes.
>>>
>>> The "three part model (issuer, holder, verifier)" involves more entities
>>> / components: the user, the TEE (Trusted Execution Environment)
>>> supported by the smart phone or tablet manufacturer, Trusted
>>> Applications (TAs) placed into the TEE, the providers of these Trusted
>>> Applications (TAs)
>>> and the RichOS supported by the smart phone or tablet. Security and
>>> privacy concerns can only be achieved while considering the whole chain.
>>>
>>> The protocols between an holder and a verifier are rather different from
>>> those defined din OAuth, since in many cases they support Zero-Knowledge
>>> proofs (ZKPs).
>>>
>>> Before designing an architecture, it is important to raise the following
>>> questions:
>>>
>>>- Is it desirable to support linkability between verifiers and/or
>>>unlinkability between verifiers ?
>>>- How to bind a Verifiable Presentation to its legitimate holder
>>>while also supporting the unlinkability property between verifiers ?
>>>
>>> IMO, bridging the architectural narrative used in the core OAuth
>>> framework (AS, RS, RO) and three part model (issuer, holder, verifier) is
>>> not desirable.
>>> This would add confusion. Extending the OAuth charter to address the "three
>>> part model" is not desirable.
>>>
>>> Some committees and foundations are already addressing this topic, e.g.,
>>> W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform
>>> (for the TEE).
>>>
>>>

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[Tom Jones]

Kind of interesting to consider this to be a security consideration. It
depends on whose security is being considered. I have always thought that
the only way for the subject to approach a request for data is as a privacy
threat. The attacker is the "client" every time. Sometimes it is something
attacking the client, but the client is the data fiduciary.

The actual threat to the client is running a foul of the GDPR. The
penalties can be pretty high. Maybe this should be called privacy or
conduct risk. In any case there needs to be corporate policy imposed on the
developers.

thx ..Tom (mobile)

On Tue, Sep 26, 2023, 8:31 AM George Fletcher  wrote:

> Hi Justin,
>
> Whether the scopes are known or unknown to the developer, I don't think it
> changes the "attack vector" which is to get the client to request more
> privilege than it should in a given circumstance. Maybe the attacker has a
> way to capture the token once it issues (this of course can be mitigated by
> using sender constrained tokens but how many are deploying that solution
> internally?).
>
> I think a security consideration makes sense given the client is likely
> just going to use whatever is provided in the meta-data. Either the AS
> needs a way to ensure clients only request the authorization needed for the
> current task, or clients need a way to filter the scopes specified. The
> latter is more likely but we don't have a good way to convey the intent of
> the access token outside of the Resource Indicators specification (which
> again I'm not sure is widely implemented).
>
> Thanks,
> George
>
> On Tue, Sep 26, 2023 at 10:54 AM Justin Richer  wrote:
>
>> I think we’re used to thinking of scopes in terms of things that a
>> developer can read and understand, but that’s not always going to be true.
>> For automated systems like this, the developer isn’t always expected to
>> understand the scope — they probably don’t even see it in many cases. The
>> client software knows the API, but at the OAuth layer, the client just
>> needs to know what values to put into the OAuth flow to be able to call the
>> RS and have it work. That value could very well be an opaque string, which
>> is supported by the 6750 response header already as well.
>>
>>  — Justin
>>
>> On Sep 22, 2023, at 1:58 PM, Atul Tulshibagwale  wrote:
>>
>> Hi,
>>
>> #1 is clear now. Thanks Warren
>> On #2, thanks Neil and Warren for your clarifications. Does it make sense
>> to include language that warns against requesting unknown scopes in the
>> OPRM draft?
>>
>> Atul
>>
>> On Thu, Sep 21, 2023 at 11:17 AM Neil Madden 
>> wrote:
>>
>>> On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:
>>>
>>>
>>> Hi all,
>>> I'm still looking for answers to these two questions
>>> 
>>> regarding the OPRM draft that was recently adopted by the WG:
>>>
>>>1. If I have a resource server that has multiple endpoints, each of
>>>which require different scopes, how should those be handled? For example,
>>>in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a
>>>Polling endpoint. The scopes required for these are different. How would
>>>the client know which scope is to be used with which endpoint?
>>>2. Does the spec encourage insecure behavior in the caller by
>>>requesting tokens with scopes that they do not understand? I.e. If an
>>>authorization server is known to provide valuable tokens with certain
>>>scopes, can a malicious resource server trick the client into requesting 
>>> a
>>>more powerful token, which it then uses to access some other service? 
>>> Since
>>>the consent dialog is likely to show two trusted names (i.e. the 
>>> requesting
>>>client and the authorization server), the user would be prone to 
>>> providing
>>>consent, even if the scope looks unnecessarily permissive.
>>>
>>> Regarding point 2, if this is a threat then it's already enabled by RFC
>>> 6750, which defines the `WWW-Authenticate: Bearer scope="..."` challenge
>>> header that can be used to indicate which scopes a client needs to access a
>>> resource. Even just misleading documentation for how to access the RS could
>>> enable this threat. That's not to say that this isn't worth considering (it
>>> is), but I don't think this draft makes the situation worse than now.
>>>
>>> -- Neil
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>>
>> https://urldefense.com/v3/__

Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List

[Tom Jones]

Attackers do not stick to the rules. It sounds to me like one of the
security considerations for any standard that employs json, or any other
structured data language, is to ensure that the input is validated to be
compliant. I have been in the position of trying to enforce type checking
on experienced dev teams and been told that type checking should happen
before they get the data.

thx ..Tom (mobile)

On Tue, Oct 3, 2023, 8:02 AM Watson Ladd  wrote:

> On Mon, Oct 2, 2023, 11:56 PM Denis  wrote:
> >
> > Hi Justin,
> >
> > Your premise relies on a feature of JSON that does not exist. JSON does
> not provide well-defined behavior for repeated names within an object:
> >
> > When the names within an object are not
> > unique, the behavior of software that receives such an object is
> > unpredictable.
> >
> > You should also cite the next two sentences which are:
> >
> >Many implementations report the last name/value pair only.  Other
> implementations report an error or fail
> >to parse the object, and some implementations report all of the
> name/value pairs, including duplicates.
> >
> > A specification might require to use implementations that report all of
> the name/value pairs, including duplicates.
>
> That's not sticking to JSON semantics. Extending JSON to be a
> multifunction or worse a sequence of key value pairs changes the
> semantics. If you use JSON stick to RFC 8259 as it interoperates not
> gratuitously cause problems.
>
> Justin is right.
>
> Sincerely,
> Watson Ladd
>
> ___
> 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

Re: [OAUTH-WG] SD-JWT Redaction Reasons

[Tom Jones]

That's leaking the existence of PII. That requires permission of the
subject. I think it's way more complicated than you think.

thx ..Tom (mobile)

On Tue, Oct 17, 2023, 6:20 AM Orie Steele  wrote:

> Hello,
>
> In government documents that feature redaction, it's common for the
> redaction to be given a reason.
>
> For example, in the Mueller report, we can see "Harm to Ongoing Matter",
> "Personal Privacy", "Investigative Technique", as well as "IT" and "HOM".
>
> In SD-JWT we see the following:
>
> Case 1
>
> "_sd": [
>   "IjCRF...znc", // disclosure hash
>   "Qdpt9pL...lhU9UDo" // disclosure hash
> ]
>
> and
>
> Case 2
>
> { "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash  }
>
> After verification and applying disclosures these annotations are no
> longer present.
>
> I wonder if it would be worth allowing a reason for why a holder might
> have retained a redaction (or chose not to disclose for a reason).
>
> Since the payload is committed to by the issuer, this information would
> have to be present in the disclosures collection for the SD-JWT.
>
> Here is an example disclosure:
>
> [
>   "8UbQ9NZ6xseoDqMW_Bd50A", // salt
>   "type", // json object key (always a string)
>   [ // json object value
> "VerifiableCredential",
> "ExampleAlumniCredential"
>   ]
> ]
>
> Consider the following strawman syntax for disclosing a redaction reason:
>
> {
>   "disclosure hash" : "Personal Privacy" || "Harm to Ongoing Matter"
> }
>
> This allows a UI to map the redaction reason into a presentation (ui)
> layer for the issuer secured payload.
>
> Since it's an unsecured object, it can be extended with other fields at
> the discretion of the holder or issuer.
>
> However it might be secured by nesting it inside another JWT or SD-JWT.
>
> It would only slightly complicate the verification logic, you would need
> to filter any encoded disclosures by the `ey` prefix, since they will never
> be found in the payload, as we know they will hash differently than array
> encoded disclosures, which will be found in the payload.
>
> I'll be giving a presentation on this topic to the W3C Credentials
> community group later today, happy to shuttle their reactions back to this
> list.
>
> Apologies if this has been discussed previously.
>
> Regards,
>
> OS
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> 
> ___
> 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

Re: [OAUTH-WG] sub_id in draft for Transaction tokens

[Tom Jones]

It makes sense to me that the sub should always be the subject of an issued
token.

thx ..Tom (mobile)

On Sun, Oct 29, 2023, 7:54 PM Justin Richer  wrote:

> I disagree with the utility of just "sub" here. The subject of the token
> is always contextual to the issuer of that subject - however, the "iss"
> field here is the issuer of the transaction token and not the issuer of the
> subject identifier. As such, it's much less ambiguous to use the compound
> field. The concerns are similar to SET, where sub_id was initially defined
> - - the source context for the subject can't be assumed to be the same as
> that of the transaction token.
>
> -Justin
> --
> *From:* OAuth  on behalf of Atul Tulshibagwale <
> a...@sgnl.ai>
> *Sent:* Thursday, October 26, 2023 4:07 PM
> *To:* Kai Lehmann 
> *Cc:* oauth@ietf.org 
> *Subject:* Re: [OAUTH-WG] sub_id in draft for Transaction tokens
>
> Hi Kai,
> Thanks for this and other feedback you have provided.
>
> The primary reason for using "sub_id" was to enable a format that can be
> more expressive than the "sub", which is always a string.
>
> I can see the benefit of having either "sub" or "sub_id" in the
> Transaction Tokens spec. "sub" will allow for more compact tokens where a
> richer subject format is not required.
>
> Atul
>
>
> On Thu, Oct 26, 2023 at 1:52 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi all,
>
>
>
> I very much like the draft. We have a similar token mechanism implemented
> for our service infrastructure.
>
>
>
> I am not quite sure about the reasoning behind using “sub_id” for the
> subject identifier instead of using “sub” as used across OAuth technology.
> The referenced draft for SubjectIdentifiers is related to a security event
> environment. The origin of the sub can be manifold in those scenarios. In
> the OAuth environment, on the other hand, we do usually have the original
> access token at the beginning of the call and there, a sub is usually
> present and well defined within the trust boundary.
>
>
>
> In our implementation, we simply create an internal token (that’s our term
> for it) and copy the sub from the AT. We have a few entry points where we
> do not have a user interaction (for instance incoming mail via SMTP which
> needs to be delivered to the end-users mailbox storage). In those
> scenarios, we allow the very small list of gateways (e.g. SMTPD) to call
> the token exchange with other parameters than the AT. The recipient email
> address needs to be provided which is being used to look up the actual
> subject identifier (in our case it’s a UUID tied to the user account) which
> is put into the created internal token. This way we ensure that the “sub”
> claim is always the same type/format. The internal services do not need to
> interpret/support multiple formats as they can rely on the token exchange
> server to provide it.
>
>
>
> The referenced draft for subject identifiers for security events allows
> for the “sub” in parallel to the “sub_id”. My suggestion would be to allow
> to use either “sub” or “sub_id”. I would use “sub” as long as all parties
> (workloads) within the trust boundary understand what the sub value is and
> it is guaranteed that the transaction tokens are generated with the same
> sub format/type.
>
>
>
> Best regards,
>
> Kai
>
>
> ___
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [External Sender] Call for adoption - Identity Chaining

[Tom Jones]

This sounds like an attempt to re-enable 3rd party cookies.
Are you seriously considering allowing access to a user's camera from one
client to another w/o user consent?
This is the sort of stuff that gives the web a bad name!
..tom


On Tue, Nov 14, 2023 at 10:20 AM Atul Tulshibagwale  wrote:

> I support the adoption
>
> On Tue, Nov 14, 2023 at 6:49 AM George Fletcher  40capitalone@dmarc.ietf.org> wrote:
>
>> I'm supportive of adoption
>>
>> On Tue, Nov 14, 2023 at 7:59 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is an *official* call for adoption for the *Identity Chaining *
>>> draft:
>>>
>>> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/
>>> 
>>>
>>> Please, reply on the mailing list and let us know if you are in favor or
>>> against adopting this draft as WG document, by *Nov 28th.*
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>>
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!OyC9xgtqotJNHW3koj1oIIQd6r1xpEp306TlRaAR5PkNtTgd_RSn1BNImQBv_LGsRvUx0Qrpv0r1QWeXG-9cGD4L6_dsONA$
>>>
>> --
>>
>> The information contained in this e-mail may be confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the intended
>> recipient, you are hereby notified that any review, retransmission,
>> dissemination, distribution, copying or other use of, or taking of any
>> action in reliance upon this information is strictly prohibited. If you
>> have received this communication in error, please contact the sender and
>> delete the material from your computer.
>>
>>
>>
>>
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt

[Tom Jones]

I agree with Mike. This exercise seems to add confusion rather than clarity.

thx ..Tom (mobile)

On Tue, Nov 28, 2023, 10:05 AM Michael Jones 
wrote:

> Orie, you wrote:
>
>
>
> TLDR; TallTed believes that the convention in the JWT BCP is not correct:
>
> https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing
>
> So instead of seeing:
>
> application/secevent+jwt
>
> We should be seeing:
>
> application/jwt; profile=secevent
>
>
>
> For what it's worth, the authors of the JWT BCP believed that the use of
> application/*subtype*+jwt works well for explicit typing, and so put it
> into the specification.  The IETF-wide review and the IESG review supported
> this decision.  I don’t see grounds to revise it.
>
>
>
> I personally believe that adding media type parameters when using media
> type names reduces interoperability.  Code gets the string comparison for
> media type names right and tends to screw up on media type parameters in
> various ways because they’re largely unexpected.  Rather than adding the
> use of media type parameters, I would prefer that the registrations be
> updated to prohibit their use.
>
>
>
>-- Mike
>
>
>
> -Original Message-
> From: OAuth  On Behalf Of Carsten Bormann
> Sent: Monday, November 27, 2023 7:32 AM
> To: Orie Steele 
> Cc: oauth ; IETF Media Types 
> Subject: Re: [OAUTH-WG] Request to add a profile parameter to +jwt and
> +sd-jwt
>
>
>
> On 2023-11-27, at 15:55, Orie Steele  wrote:
>
> >
>
> > application/jwt; profile=secevent
>
> >
>
> > This is a general form of the challenges associated with using multiple
> structured suffixes with JWTs.
>
>
>
> Anything that reduces our need to extract semantics from complex nested
> structured suffixes is good.
>
>
>
> Independent of which form is being used here, I’d like to raise the
> specter of ossification:
>
>
>
> Will we be able to evolve the profile name (nested media type subtype)
> once a subtype/profile is in wide use?
>
> (I think in the end we will exactly do that TLS 1.3 did: send fake TLS 1.2
> identification and do the recognition of TLS 1.3 on a higher level.)
>
>
>
> Grüße, Carsten
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7C%7C7dbe85583aa74167f5b608dbef5e1c2a%7C84df9e7fe9f640afb435%7C1%7C0%7C638366959703680014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FMVqVsRxxd7Y4hxEC2T5iSUB0wV84ASM5FQW8TYqRkY%3D&reserved=0
> 
> ___
> 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

Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt

[Tom Jones]

ya know - there was a time when a standard could have a conformance test
and then the implementations worked together.
Now standards are just wishful thinking.  Something MIGHT work, or might
not.
interop was a feature of a standard. Now the standard is wishful thinking
and interop profile comes after the std is published. (maybe)
..tom


On Tue, Nov 28, 2023 at 11:15 AM David Waite 
wrote:

> Media type parameters are useful for subtypes that add a multitude of
> expansion options, such as multimedia formats with a multitude of codecs,
> encoding options, and profiles to define feature sets.
>
> The best usages of them I’ve seen is supplemental.
>
> A baseline JWT isn’t really able to be customized in that way; even though
> it has defined claim names and meanings there conventions and
> considerations expected to be defined by a particular application of JWT
>
> Secevents or a JWT credential might define parameterization. For example,
> a credential might describe itself as having particular types/profiles of
> claims about a subject, such as being usable as a driving license and as a
> primary government-issued identification.
>
> -DW
>
> On Nov 28, 2023, at 1:24 PM, Tom Jones 
> wrote:
>
> 
> I agree with Mike. This exercise seems to add confusion rather than
> clarity.
>
> thx ..Tom (mobile)
>
> On Tue, Nov 28, 2023, 10:05 AM Michael Jones 
> wrote:
>
>> Orie, you wrote:
>>
>>
>>
>> TLDR; TallTed believes that the convention in the JWT BCP is not correct:
>>
>> https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing
>>
>> So instead of seeing:
>>
>> application/secevent+jwt
>>
>> We should be seeing:
>>
>> application/jwt; profile=secevent
>>
>>
>>
>> For what it's worth, the authors of the JWT BCP believed that the use of
>> application/*subtype*+jwt works well for explicit typing, and so put it
>> into the specification.  The IETF-wide review and the IESG review supported
>> this decision.  I don’t see grounds to revise it.
>>
>>
>>
>> I personally believe that adding media type parameters when using media
>> type names reduces interoperability.  Code gets the string comparison for
>> media type names right and tends to screw up on media type parameters in
>> various ways because they’re largely unexpected.  Rather than adding the
>> use of media type parameters, I would prefer that the registrations be
>> updated to prohibit their use.
>>
>>
>>
>>-- Mike
>>
>>
>>
>> -Original Message-
>> From: OAuth  On Behalf Of Carsten Bormann
>> Sent: Monday, November 27, 2023 7:32 AM
>> To: Orie Steele 
>> Cc: oauth ; IETF Media Types 
>> Subject: Re: [OAUTH-WG] Request to add a profile parameter to +jwt and
>> +sd-jwt
>>
>>
>>
>> On 2023-11-27, at 15:55, Orie Steele  wrote:
>>
>> >
>>
>> > application/jwt; profile=secevent
>>
>> >
>>
>> > This is a general form of the challenges associated with using multiple
>> structured suffixes with JWTs.
>>
>>
>>
>> Anything that reduces our need to extract semantics from complex nested
>> structured suffixes is good.
>>
>>
>>
>> Independent of which form is being used here, I’d like to raise the
>> specter of ossification:
>>
>>
>>
>> Will we be able to evolve the profile name (nested media type subtype)
>> once a subtype/profile is in wide use?
>>
>> (I think in the end we will exactly do that TLS 1.3 did: send fake TLS
>> 1.2 identification and do the recognition of TLS 1.3 on a higher level.)
>>
>>
>>
>> Grüße, Carsten
>>
>>
>>
>> ___
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7C%7C7dbe85583aa74167f5b608dbef5e1c2a%7C84df9e7fe9f640afb435%7C1%7C0%7C638366959703680014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FMVqVsRxxd7Y4hxEC2T5iSUB0wV84ASM5FQW8TYqRkY%3D&reserved=0
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> ___
>> 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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Errata Rejected] RFC7519 (5648)

[Tom Jones]

Pronounce jwt as tho it were a Welsh word. It comes out close.  More like
joot

thx ..Tom (mobile)

On Thu, Jan 11, 2024, 6:53 PM RFC Errata System 
wrote:

> The following errata report has been rejected for RFC7519,
> "JSON Web Token (JWT)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5648
>
> --
> Status: Rejected
> Type: Editorial
>
> Reported by: Andy Delcambre 
> Date Reported: 2019-03-08
> Rejected by: Roman Danyliw (IESG)
>
> Section: 1
>
> Original Text
> -
> JSON Web Token (JWT) is a compact claims representation format
>intended for space constrained environments such as HTTP
>Authorization headers and URI query parameters.  JWTs encode claims
>to be transmitted as a JSON [RFC7159] object that is used as the
>payload of a JSON Web Signature (JWS) [JWS] structure or as the
>plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
>the claims to be digitally signed or integrity protected with a
>Message Authentication Code (MAC) and/or encrypted.  JWTs are always
>represented using the JWS Compact Serialization or the JWE Compact
>Serialization.
>
>The suggested pronunciation of JWT is the same as the English word
>"jot".
>
>
>
> Corrected Text
> --
> JSON Web Token (JWT) is a compact claims representation format
>intended for space constrained environments such as HTTP
>Authorization headers and URI query parameters.  JWTs encode claims
>to be transmitted as a JSON [RFC7159] object that is used as the
>payload of a JSON Web Signature (JWS) [JWS] structure or as the
>plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
>the claims to be digitally signed or integrity protected with a
>Message Authentication Code (MAC) and/or encrypted.  JWTs are always
>represented using the JWS Compact Serialization or the JWE Compact
>Serialization.
>
>
> Notes
> -
> The suggested pronunciation is strange and confusing. It makes it hard to
> onboard new people verbally and always requires an explanation of the
> pronunciation. The standard already has a perfectly reasonable initialism
> of JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a
> pronunciation that does not map to the letters of the spec, and in my
> experience often leads to confusion when used.
>  --VERIFIER NOTES--
> This guidance was produced with the consensus of the WG.  Per
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/,
> "Errata are items that were errors at the time the document was published"
>
> --
> RFC7519 (draft-ietf-oauth-json-web-token-32)
> --
> Title   : JSON Web Token (JWT)
> Publication Date: May 2015
> Author(s)   : M. Jones, J. Bradley, N. Sakimura
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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

Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

The big problem is that standards bodies all over the spectrum are creating
attestations without even bothering to see what is happening in other
communities. The verifier will have many attestations to choose from and
will thus choose to do nothing with any of them. Perhaps it is time to ask
a verifier what problems they have instead of telling how to fix problems
they don't have currently? If it is really this hard to get this new stuff
to work, perhaps the new stuff is not well-designed to begin with? ..tom


On Thu, Jan 18, 2024 at 1:27 AM Denis  wrote:

> Typo: Change: "proof *or* origin of wallet instance"
> into   : "proof *of* origin of wallet instance".
>
> The figure has been corrected below.
>
> Denis
>
> Hi Giuseppe,
>
> The current figure in the Introduction from
> draft-demarco-status-attestations-latest is:
>
> +-+ +---+
> | | Requests Status Attestation |   |
> | |>|   |
> | Wallet Instance | | Credential Issuer |
> | | Status Attestation  |   |
> | |<|   |
> +-+ +---+
>
>
> +-- + +--+
> |   | Presents credential and |  |
> |  Wallet Instance  | Status Attestation  | Verifier |
> |   |>|  |
> +---+ +--+
>
> IMO, using the vocabulary agreed during the last BoF video conference,
> this figure should be modified as follows:
>
>
> ++
> +---+
> || Requests *Digital Credential*|
> |
> || and presents proof of knowledge of |
> |
> || either a private key or a link secret  |
> |
> || and proof *of* origin of wallet instance | Credential
> Issuer |
> |   Holder   |--->|
> |
> |||
> |
> ||*Digital Credential*  |
> |
> ||<---|
> |
> ++
> +---+
>
>
> +-- -+
> +---+
> || Presents *Credential proof*  |
>|
> |   Holder   ||  Verifier
> |
> ||--->|
> |
> ++
> +---+
>
> Denis
>
>
> Hi Hannes,
>
> Thank you for your quick reaction and also to Orie for sharing.
> I've submitted the draft, here:
> https://datatracker.ietf.org/doc/draft-demarco-status-attestations/
>
> Regarding the term Attestation: good point. We have decided to use this
> term since in several IETF and OpenID drafts this term seems pretty
> established, the term Attestation is found at least in the following
> specifications:
>   - Attestation based client-authentication (it's in the title)
>   - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC
> (wallet attestation)
>   - OpenID for Verifiable Presentations - draft 20 (verifier attestation)
>   - OpenID for Verifiable Credential Issuance (section "Trust between
> Wallet and Issuer": Device Attestation)
>
> Meantime in the eIDAS Expert group this term is going to be changed to
> "Wallet Trust Evidence".
>
> 
> I don't have a strong opinion on what would be the best semantic for this,
> I just have realized the functional difference between a Digital Credential
> and an Attestation:
> the first requires the user to be authenticated and give consent for using
> the secure storage. The second is obtained with a machine2machine flow
> where no user interaction is required, the secure storage is not required,
> no user information is contained in it since the subject is the wallet
> instance and not the user, it cannot be (re)used without the cryptographic
> proof of possession. Probably a discussion could start about this term
> aiming to align several specifications on the same terminology. I could say
> that Status Attestation is a specific artifact defined for a specific
> context, other attestations can be defined outside the functional perimeter
> of this specification. Let's talk about it, it doesn't matters changing
> terms (eventually mindsets on perceivable meanings).
>
> Here I share some notes I picked along the last two months about this
> brand new individual draft:
>
> - it is related to digital credential only, I don't expect to use it in
> legacy infrastructure different from wallet. I really don't need this kind
> of mechanism in OIDC or any other traditional infrastructure since these
> doesn't show the pr

Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

it is very presumptuous for you to tell the verifier what they must do.
Why do you think they will pay any attention to you?
Be the change you want to see in the world ..tom


On Thu, Jan 18, 2024 at 10:39 AM Giuseppe De Marco <
gi.dema...@innovazione.gov.it> wrote:

> Hi Tom,
>
> let's try to align ourself, then it will be more natural.
>
> The Verifier has the requirement to verify the validitiy of the
> presentations and verify that the credentials are still valid and then not
> revoked. This is the "what".
>
> The "how" can bring several solutions:
>
>
>- OAuth Status List for realtime checks where the RP interacts
>directly with the status list provider
>- OAuth Status Attestation where the RP interacts  directly with the
>wallet instance
>
>
> The flows above are definitely different, first of all the entities
> involved are different. Since the wallet instance must provide the
> presentation, it also adds the attestations about the non revocation of
> these, in a single shot. It works also in proxmity flow, where the Verifier
> doesn't have internet (since it can establish the trust with the wallet
> solution and the credential issuer just by having the public key of the
> Trust Anchor ... old story!).
>
> In terms of presentation request the RP would not add the status
> attestation in the presentation definition, if the credential carries the
> status.status_attestation object this is the element that gives to the RP
> the hint to looks in the vp_tokens for the status attestation.
>
> and they all lived happily ever after, please help me find some problem
>
>
> --
> *Da:* Tom Jones 
> *Inviato:* giovedì 18 gennaio 2024 18:43
> *A:* Denis 
> *Cc:* demarcog83 ; hannes.tschofenig=
> 40gmx@dmarc.ietf.org ;
> sp...@ietf.org ; Francesco Antonio Marino <
> fa.mar...@ipzs.it>; Giuseppe De Marco ;
> oauth 
> *Oggetto:* Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status
> Attestations (typo)
>
> Non si ricevono spesso messaggi di posta elettronica da
> thomasclinganjo...@gmail.com. Informazioni sul perché è importante
> <https://aka.ms/LearnAboutSenderIdentification>
>
> The big problem is that standards bodies all over the spectrum are
> creating attestations without even bothering to see what is happening in
> other communities. The verifier will have many attestations to choose from
> and will thus choose to do nothing with any of them. Perhaps it is time to
> ask a verifier what problems they have instead of telling how to fix
> problems they don't have currently? If it is really this hard to get this
> new stuff to work, perhaps the new stuff is not well-designed to begin
> with? ..tom
>
>
> On Thu, Jan 18, 2024 at 1:27 AM Denis  wrote:
>
> Typo: Change: "proof *or* origin of wallet instance"
> into   : "proof * of* origin of wallet instance".
>
> The figure has been corrected below.
>
> Denis
>
> Hi Giuseppe,
>
> The current figure in the Introduction from
> draft-demarco-status-attestations-latest is:
>
> +-+ +---+
> | | Requests Status Attestation |   |
> | |>|   |
> | Wallet Instance | | Credential Issuer |
> | | Status Attestation  |   |
> | |<|   |
> +-+ +---+
>
>
> +-- + +--+
> |   | Presents credential and |  |
> |  Wallet Instance  | Status Attestation  | Verifier |
> |   |>|  |
> +---+ +--+
>
> IMO, using the vocabulary agreed during the last BoF video conference,
> this figure should be modified as follows:
>
>
> ++
> +---+
> || Requests *Digital Credential*|
> |
> || and presents proof of knowledge of |
> |
> || either a private key or a link secret  |
> |
> || and proof *of* origin of wallet instance | Credential
> Issuer |
> |   Holder   |--->|
> |
> |||
> |
> ||*Digital Credential*  |
> |
> ||<---|
> |
> ++
> +---

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

Proof seems to be yet another term for which we already have other terms.
Can anyone explain the difference between:
proof
presentation
evidence.

..tom


On Fri, Jan 19, 2024 at 4:28 AM Denis  wrote:

> Hi Giuseppe,
>
> Ciao Denis,
>
> Thank you! By points.
>
> First, I still have a vocabulary problem. The text states:
>
> A *digital credential* may be presented to a verifier long after it has
> been issued.
>
> It should rather say: A *digital proof *(derived from a digital
> credential) may be presented to a verifier.
>
> Then, the text states:
>
> Verifier:
>
> Entity that relies on the validity of the Digital Credentials presented to
> it.
>
> I should rather say:
>
> Verifier:
>
>   Entity that relies on the validity of the *digital proof*
> presented to it.
>
>
> OAuth Status List can be accessed by a Verifier when an internet
> connection is present.
>
>- This does not correspond to the flows of the figure.
>
>
> the section enumerates the differences between oauth status list and oauth
> status attestations.
> The subject of the sentence is then the oauth status list, below I report
> the original text in that point:
>
> *Offline flow*: OAuth Status List can be accessed by a Verifier when an
> internet connection is present. At the same time, OAuth Status List defines
> how to provide a static Status List Token, to be included within a Digital
> Credential. This requires the Wallet Instance to acquire a new Digital
> Credential for a specific presentation. Even if similar to the OAuth Status
> List Token, the Status Attestations enable the User to persistently use
> their preexistent Digital Credentials, as long as the linked Status
> Attestation is available and presented to the Verifier, and not expired.
>
>  OK.
>
>
>
>- What about the support of "blinded link secrets" and "link secrets"
>(used with anonymous credentials) ?
>
>
> Unfortunately I don't have these in the EUDI ARF and in my implementative
> asset but this doesn't prevent us to not include it in the draft.
>
> When writing this, I had the use case of BBS+ in mind.
>
> Published versions of the ARF is available here:
> https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md
>
> The word "privacy" is used once in a single sentence copied below which is:
>
> Attestation exchange Protocol. This protocol defines how to request and
> present the PID and the (Q)EAA in a secure and *privacy* preserving
> fashion.
>
> In the context of a single data controller, ISO 29100 identifies eleven
> privacy principles:
>
> 1.   Consent and choice
> 2.   Purpose legitimacy and specification
> 3.   Collection limitation
> 4.   Data minimization
> 5.   Use, retention and disclosure limitation
> 6.   Accuracy and quality
> 7.   Openness, transparency and notice
> 8.   Individual participation and access
> 9.   Accountability
> 10. Information security
> 11. Privacy compliance
>
> None of them is being addressed.
>
> In addition, when considering a distributed system used by human beings, *two
> additional **privacy principles *need to be taken into consideration
> and none of them is mentioned:
>
> *  Unlinkability *of holders between verifiers
>
> *  Untrackability* of holders by a server, (i.e., a property ensuring
> that it is not possible for a server to know by which verifier the
> information it issues to a caller,
> or derivations from it, will be consumed.
> In other words : Can the server act as Big Brother ?
>
> Margrethe *Vestager*, [former] Executive Vice-President for a Europe Fit
> for the Digital Age said:
>
> *  “The European digital identity will enable us to do in any Member
> State as we do at home without any extra cost and fewer hurdles. *
> *  Be that renting a flat or opening a bank account outside of our
> home country. And do this in a way that is secure and transparent. *
> *  So that we will decide how much information we wish to share about
> ourselves, with whom and for what purpose.*
>
> Source:  https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2663
>
> This statement is not mentioned in the ARF.
>
> An additional important *security consideration *needs to be addressed:
>
> *  Collusions between **holders *(natural persons), which is
> difficult to support while at the same time the "*collection limitation*"
> privacy principle is considered.
>
> This can be illustrated by the following example:
>
>   Can Alice (12) collude with Bob (25) to access to a verifier
> delivering age-restricted services or products (e.g., like the condition of
> being over 18) ?
>  Since Bob is over 25, he can obtain some "proof" that he is over 18.
> Can Alice (12) can advantage of this proof to access to age-restricted
> services or products ?
>
> Would you like to propose your idea in the current text (github issue or
> PR) about the possibility to enable this technology?
>
> On page 

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

yes - i see that's what you are doing and think it is not only wrong, but
misleading.
Somehow words like trust and proof are given technological definitions by
technologists that do not reflect the words existing meaning, but seek to
gain reflected credence by their use in technological contexts. .  (like
proof -> a cryptographic ability that is verifiable)
Perhaps you don't care that these are incorrect uses of the word?

..tom


On Fri, Jan 19, 2024 at 10:46 AM  wrote:

> You present evidence as proof.
>
>
> On 2024-01-19 12:50, Tom Jones wrote:
>
>
> Proof seems to be yet another term for which we already have other terms.
> Can anyone explain the difference between:
> proof
> presentation
> evidence.
>
> ..tom
>
> On Fri, Jan 19, 2024 at 4:28 AM Denis  wrote:
>
> Hi Giuseppe,
>
> Ciao Denis,
>
> Thank you! By points.
>
> First, I still have a vocabulary problem. The text states:
>
> A *digital credential* may be presented to a verifier long after it has
> been issued.
>
> It should rather say: A *digital proof *(derived from a digital
> credential) may be presented to a verifier.
>
> Then, the text states:
>
> Verifier:
>
> Entity that relies on the validity of the Digital Credentials presented to
> it.
>
>
> I should rather say:
>
> Verifier:
>
>   Entity that relies on the validity of the *digital proof*
> presented to it.
>
>
>
> OAuth Status List can be accessed by a Verifier when an internet
> connection is present.
>
>- This does not correspond to the flows of the figure.
>
>
> the section enumerates the differences between oauth status list and oauth
> status attestations.
> The subject of the sentence is then the oauth status list, below I report
> the original text in that point:
>
> *Offline flow*: OAuth Status List can be accessed by a Verifier when an
> internet connection is present. At the same time, OAuth Status List defines
> how to provide a static Status List Token, to be included within a Digital
> Credential. This requires the Wallet Instance to acquire a new Digital
> Credential for a specific presentation. Even if similar to the OAuth Status
> List Token, the Status Attestations enable the User to persistently use
> their preexistent Digital Credentials, as long as the linked Status
> Attestation is available and presented to the Verifier, and not expired.
>
>  OK.
>
>
>
>- What about the support of "blinded link secrets" and "link secrets"
>(used with anonymous credentials) ?
>
>
> Unfortunately I don't have these in the EUDI ARF and in my implementative
> asset but this doesn't prevent us to not include it in the draft.
>
> When writing this, I had the use case of BBS+ in mind.
>
> Published versions of the ARF is available here:
> https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md
>
> The word "privacy" is used once in a single sentence copied below which is:
>
> Attestation exchange Protocol. This protocol defines how to request and
> present the PID and the (Q)EAA in a secure and *privacy* preserving
> fashion.
>
> In the context of a single data controller, ISO 29100 identifies eleven
> privacy principles:
>
> 1.   Consent and choice
> 2.   Purpose legitimacy and specification
> 3.   Collection limitation
> 4.   Data minimization
> 5.   Use, retention and disclosure limitation
> 6.   Accuracy and quality
> 7.   Openness, transparency and notice
> 8.   Individual participation and access
> 9.   Accountability
> 10. Information security
> 11. Privacy compliance
>
> None of them is being addressed.
>
> In addition, when considering a distributed system used by human beings, *two
> additional **privacy principles *need to be taken into consideration
> and none of them is mentioned:
>
> *  Unlinkability *of holders between verifiers
>
> *  Untrackability* of holders by a server, (i.e., a property ensuring
> that it is not possible for a server to know by which verifier the
> information it issues to a caller,
> or derivations from it, will be consumed.
> In other words : Can the server act as Big Brother ?
>
> Margrethe *Vestager*, [former] Executive Vice-President for a Europe Fit
> for the Digital Age said:
>
> *  "The European digital identity will enable us to do in any Member
> State as we do at home without any extra cost and fewer hurdles. *
> *  Be that renting a flat or opening a bank account outside of our
> home country. And do this in a way that is secure and transparent. *
> *  So that we wil

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

Technically oauth is about authorization not authentication. And
technically attestation is provided by rats and not oauth. So if you think
that you are confused, so is everyone else at this point.

thx ..Tom (mobile)

On Sun, Jan 21, 2024, 11:51 AM  wrote:

> Hi Tom et al.
>
> Earlier this or last week someone wrote about the possibility of looking
> at things from a relying party's perspective.
>
> As a relying party I need a method for a user to prove who and what they
> are or have. Hence the user needs to present evidence as proof of who they
> are and in what capacity or holding they are presenting.
>
> I have been very involed in SSI and verfiable credentials (VC). Which is
> becoming a major way of presentiing evidence as proof.
>
> VCs are cryptographic proofs for a relying party. However the relying
> party also needs proof of who is presenting.  WShen you combine the two you
> now address proof of possession problem which has been the underlying
> weakness of public key cryptography.
>
> I was not trying to be misleading. I  was responding to the discussion
> below regarding " digital proof, digital credential, secure and privacy
> preserving fashion, collusion between holders, collection limitation,
> privacy principles, unlinkability between verifiers and more.
>
> I have done a lot of work in this area and believe have addressed the
> proof of possession issue of public key cryptography because I can
> cryptographically and privately bind a users biometrics with both their
> public and private keys and can embed the same with veriable credentials.
> Whereas when I see the OAuth work it seems to be trying to create an audit
> trail rather than solving the proof of posession by the original
> client/wallet initiating the transaction.
>
> As I said I was not trying to be misleading. At the same time I do not see
> the current OAuth track as solving this underlying proof of possesion
> problem that is needed by the relying party.
>
> Best
>
> Don
>
> And for the record I am not a technologist. I am a person who tries to
> solve business problems.
>
>
>
> On 2024-01-21 11:08, Tom Jones wrote:
>
> yes - i see that's what you are doing and think it is not only wrong, but
> misleading.
> Somehow words like trust and proof are given technological definitions by
> technologists that do not reflect the words existing meaning, but seek to
> gain reflected credence by their use in technological contexts. .  (like
> proof -> a cryptographic ability that is verifiable)
> Perhaps you don't care that these are incorrect uses of the word?
>
> ..tom
>
> On Fri, Jan 19, 2024 at 10:46 AM  wrote:
>
> You present evidence as proof.
>
>
> On 2024-01-19 12:50, Tom Jones wrote:
>
>
> Proof seems to be yet another term for which we already have other terms.
> Can anyone explain the difference between:
> proof
> presentation
> evidence.
>
> ..tom
>
> On Fri, Jan 19, 2024 at 4:28 AM Denis  wrote:
>
> Hi Giuseppe,
>
> Ciao Denis,
>
> Thank you! By points.
>
> First, I still have a vocabulary problem. The text states:
>
> A *digital credential* may be presented to a verifier long after it has
> been issued.
>
> It should rather say: A *digital proof *(derived from a digital
> credential) may be presented to a verifier.
>
> Then, the text states:
>
> Verifier:
>
> Entity that relies on the validity of the Digital Credentials presented to
> it.
>
>
> I should rather say:
>
> Verifier:
>
>   Entity that relies on the validity of the *digital proof*
> presented to it.
>
>
>
> OAuth Status List can be accessed by a Verifier when an internet
> connection is present.
>
>- This does not correspond to the flows of the figure.
>
>
> the section enumerates the differences between oauth status list and oauth
> status attestations.
> The subject of the sentence is then the oauth status list, below I report
> the original text in that point:
>
> *Offline flow*: OAuth Status List can be accessed by a Verifier when an
> internet connection is present. At the same time, OAuth Status List defines
> how to provide a static Status List Token, to be included within a Digital
> Credential. This requires the Wallet Instance to acquire a new Digital
> Credential for a specific presentation. Even if similar to the OAuth Status
> List Token, the Status Attestations enable the User to persistently use
> their preexistent Digital Credentials, as long as the linked Status
> Attestation is available and presented to the Verifier, and not expired.
>
>  OK.
>
>
>
>- What about the support of "blinded link secrets" and

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

I should have added - if you get a verifiable presentation from a wallet
with a verifiable credential - it is my understanding that the VP is proof
possession - in the sense that the VC has been processed by the subject to
create the VP.

I started to collect some information about that here - but it is far from
complete.
https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme

..tom


On Sun, Jan 21, 2024 at 1:03 PM Tom Jones 
wrote:

> Technically oauth is about authorization not authentication. And
> technically attestation is provided by rats and not oauth. So if you think
> that you are confused, so is everyone else at this point.
>
> thx ..Tom (mobile)
>
> On Sun, Jan 21, 2024, 11:51 AM  wrote:
>
>> Hi Tom et al.
>>
>> Earlier this or last week someone wrote about the possibility of looking
>> at things from a relying party's perspective.
>>
>> As a relying party I need a method for a user to prove who and what they
>> are or have. Hence the user needs to present evidence as proof of who they
>> are and in what capacity or holding they are presenting.
>>
>> I have been very involed in SSI and verfiable credentials (VC). Which is
>> becoming a major way of presentiing evidence as proof.
>>
>> VCs are cryptographic proofs for a relying party. However the relying
>> party also needs proof of who is presenting.  WShen you combine the two you
>> now address proof of possession problem which has been the underlying
>> weakness of public key cryptography.
>>
>> I was not trying to be misleading. I  was responding to the discussion
>> below regarding " digital proof, digital credential, secure and privacy
>> preserving fashion, collusion between holders, collection limitation,
>> privacy principles, unlinkability between verifiers and more.
>>
>> I have done a lot of work in this area and believe have addressed the
>> proof of possession issue of public key cryptography because I can
>> cryptographically and privately bind a users biometrics with both their
>> public and private keys and can embed the same with veriable credentials.
>> Whereas when I see the OAuth work it seems to be trying to create an audit
>> trail rather than solving the proof of posession by the original
>> client/wallet initiating the transaction.
>>
>> As I said I was not trying to be misleading. At the same time I do not
>> see the current OAuth track as solving this underlying proof of possesion
>> problem that is needed by the relying party.
>>
>> Best
>>
>> Don
>>
>> And for the record I am not a technologist. I am a person who tries to
>> solve business problems.
>>
>>
>>
>> On 2024-01-21 11:08, Tom Jones wrote:
>>
>> yes - i see that's what you are doing and think it is not only wrong, but
>> misleading.
>> Somehow words like trust and proof are given technological definitions by
>> technologists that do not reflect the words existing meaning, but seek to
>> gain reflected credence by their use in technological contexts. .  (like
>> proof -> a cryptographic ability that is verifiable)
>> Perhaps you don't care that these are incorrect uses of the word?
>>
>> ..tom
>>
>> On Fri, Jan 19, 2024 at 10:46 AM  wrote:
>>
>> You present evidence as proof.
>>
>>
>> On 2024-01-19 12:50, Tom Jones wrote:
>>
>>
>> Proof seems to be yet another term for which we already have other terms.
>> Can anyone explain the difference between:
>> proof
>> presentation
>> evidence.
>>
>> ..tom
>>
>> On Fri, Jan 19, 2024 at 4:28 AM Denis  wrote:
>>
>> Hi Giuseppe,
>>
>> Ciao Denis,
>>
>> Thank you! By points.
>>
>> First, I still have a vocabulary problem. The text states:
>>
>> A *digital credential* may be presented to a verifier long after it has
>> been issued.
>>
>> It should rather say: A *digital proof *(derived from a digital
>> credential) may be presented to a verifier.
>>
>> Then, the text states:
>>
>> Verifier:
>>
>> Entity that relies on the validity of the Digital Credentials presented
>> to it.
>>
>>
>> I should rather say:
>>
>> Verifier:
>>
>>   Entity that relies on the validity of the *digital proof*
>> presented to it.
>>
>>
>>
>> OAuth Status List can be accessed by a Verifier when an internet
>> connection is present.
>>
>>- This does not correspond to the flows of the figure.
>>
>>

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

VPs are not reused AFAIK.

thx ..Tom (mobile)

On Mon, Jan 22, 2024, 4:41 PM Watson Ladd  wrote:

> It could be a resused one obtained from a different context. Does that
> matter? Depends on application. There's also a question of what it
> means the subject processed it: people don't process VCs, their
> computers do. (Hence the terminology of User Agent, not user, in the
> W3C)
>
>
>
> On Sun, Jan 21, 2024 at 4:46 PM Tom Jones 
> wrote:
> >
> > I should have added - if you get a verifiable presentation from a wallet
> with a verifiable credential - it is my understanding that the VP is proof
> possession - in the sense that the VC has been processed by the subject to
> create the VP.
> >
> > I started to collect some information about that here - but it is far
> from complete.
> https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme
> >
> > ..tom
> >
> >
> > On Sun, Jan 21, 2024 at 1:03 PM Tom Jones 
> wrote:
> >>
> >> Technically oauth is about authorization not authentication. And
> technically attestation is provided by rats and not oauth. So if you think
> that you are confused, so is everyone else at this point.
> >>
> >> thx ..Tom (mobile)
> >>
> >> On Sun, Jan 21, 2024, 11:51 AM  wrote:
> >>>
> >>> Hi Tom et al.
> >>>
> >>> Earlier this or last week someone wrote about the possibility of
> looking at things from a relying party's perspective.
> >>>
> >>> As a relying party I need a method for a user to prove who and what
> they are or have. Hence the user needs to present evidence as proof of who
> they are and in what capacity or holding they are presenting.
> >>>
> >>> I have been very involed in SSI and verfiable credentials (VC). Which
> is becoming a major way of presentiing evidence as proof.
> >>>
> >>> VCs are cryptographic proofs for a relying party. However the relying
> party also needs proof of who is presenting.  WShen you combine the two you
> now address proof of possession problem which has been the underlying
> weakness of public key cryptography.
> >>>
> >>> I was not trying to be misleading. I  was responding to the discussion
> below regarding " digital proof, digital credential, secure and privacy
> preserving fashion, collusion between holders, collection limitation,
> privacy principles, unlinkability between verifiers and more.
> >>>
> >>> I have done a lot of work in this area and believe have addressed the
> proof of possession issue of public key cryptography because I can
> cryptographically and privately bind a users biometrics with both their
> public and private keys and can embed the same with veriable credentials.
> Whereas when I see the OAuth work it seems to be trying to create an audit
> trail rather than solving the proof of posession by the original
> client/wallet initiating the transaction.
> >>>
> >>> As I said I was not trying to be misleading. At the same time I do not
> see the current OAuth track as solving this underlying proof of possesion
> problem that is needed by the relying party.
> >>>
> >>> Best
> >>>
> >>> Don
> >>>
> >>> And for the record I am not a technologist. I am a person who tries to
> solve business problems.
> >>>
> >>>
> >>>
> >>> On 2024-01-21 11:08, Tom Jones wrote:
> >>>
> >>> yes - i see that's what you are doing and think it is not only wrong,
> but misleading.
> >>> Somehow words like trust and proof are given technological definitions
> by technologists that do not reflect the words existing meaning, but seek
> to gain reflected credence by their use in technological contexts. .
> (like  proof -> a cryptographic ability that is verifiable)
> >>> Perhaps you don't care that these are incorrect uses of the word?
> >>>
> >>> ..tom
> >>>
> >>> On Fri, Jan 19, 2024 at 10:46 AM  wrote:
> >>>
> >>> You present evidence as proof.
> >>>
> >>>
> >>> On 2024-01-19 12:50, Tom Jones wrote:
> >>>
> >>>
> >>> Proof seems to be yet another term for which we already have other
> terms.
> >>> Can anyone explain the difference between:
> >>> proof
> >>> presentation
> >>> evidence.
> >>>
> >>> ..tom
> >>>
> >>> On Fri, Jan 19, 2024 at 4:28 AM Denis  wrot

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones]

That's far worse than I ever imagined. It seems like it's bloody well
useless. ..tom


On Tue, Jan 23, 2024 at 5:48 AM Orie Steele 
wrote:

> There are at least 2 kinds of vp.
>
> W3C has them and they can be secured or not.
>
> SD-JWT has them, and they can have key binding or not.
>
> An sd-jwt without key binding is indistinguishable from a credential
> except for looking at the unprotected disclosures.
>
> SD-JWT has a section on forwarding presentations, that talks about
> redacting fields and presenting in a cases where key binding is not
> required.
>
> Key binding is basically the secured version of a W3C VP, but restricted
> to a single credential, instead of multiple credentials.
>
> Key binding is not required afaik.
>
> Therefore presentation can be forwarded / reused.
>
> OS
>
> On Tue, Jan 23, 2024, 12:51 AM Tom Jones 
> wrote:
>
>> VPs are not reused AFAIK.
>>
>> thx ..Tom (mobile)
>>
>> On Mon, Jan 22, 2024, 4:41 PM Watson Ladd  wrote:
>>
>>> It could be a resused one obtained from a different context. Does that
>>> matter? Depends on application. There's also a question of what it
>>> means the subject processed it: people don't process VCs, their
>>> computers do. (Hence the terminology of User Agent, not user, in the
>>> W3C)
>>>
>>>
>>>
>>> On Sun, Jan 21, 2024 at 4:46 PM Tom Jones 
>>> wrote:
>>> >
>>> > I should have added - if you get a verifiable presentation from a
>>> wallet with a verifiable credential - it is my understanding that the VP is
>>> proof possession - in the sense that the VC has been processed by the
>>> subject to create the VP.
>>> >
>>> > I started to collect some information about that here - but it is far
>>> from complete.
>>> https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme
>>> >
>>> > ..tom
>>> >
>>> >
>>> > On Sun, Jan 21, 2024 at 1:03 PM Tom Jones <
>>> thomasclinganjo...@gmail.com> wrote:
>>> >>
>>> >> Technically oauth is about authorization not authentication. And
>>> technically attestation is provided by rats and not oauth. So if you think
>>> that you are confused, so is everyone else at this point.
>>> >>
>>> >> thx ..Tom (mobile)
>>> >>
>>> >> On Sun, Jan 21, 2024, 11:51 AM  wrote:
>>> >>>
>>> >>> Hi Tom et al.
>>> >>>
>>> >>> Earlier this or last week someone wrote about the possibility of
>>> looking at things from a relying party's perspective.
>>> >>>
>>> >>> As a relying party I need a method for a user to prove who and what
>>> they are or have. Hence the user needs to present evidence as proof of who
>>> they are and in what capacity or holding they are presenting.
>>> >>>
>>> >>> I have been very involed in SSI and verfiable credentials (VC).
>>> Which is becoming a major way of presentiing evidence as proof.
>>> >>>
>>> >>> VCs are cryptographic proofs for a relying party. However the
>>> relying party also needs proof of who is presenting.  WShen you combine the
>>> two you now address proof of possession problem which has been the
>>> underlying weakness of public key cryptography.
>>> >>>
>>> >>> I was not trying to be misleading. I  was responding to the
>>> discussion below regarding " digital proof, digital credential, secure and
>>> privacy preserving fashion, collusion between holders, collection
>>> limitation, privacy principles, unlinkability between verifiers and more.
>>> >>>
>>> >>> I have done a lot of work in this area and believe have addressed
>>> the proof of possession issue of public key cryptography because I can
>>> cryptographically and privately bind a users biometrics with both their
>>> public and private keys and can embed the same with veriable credentials.
>>> Whereas when I see the OAuth work it seems to be trying to create an audit
>>> trail rather than solving the proof of posession by the original
>>> client/wallet initiating the transaction.
>>> >>>
>>> >>> As I said I was not trying to be misleading. At the same time I do
>>> not see the current OAuth track as solving this underlying proof of
>>> possesion problem that is 

Re: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7782)

[Tom Jones]

The whole thing is pointless as the client owner (as opposed to the subject
for which client status is requested) can just define the instances to be
the same. There can be no way to attest to the validity of such an
assertion.

thx ..Tom (mobile)

On Fri, Jan 26, 2024, 10:42 AM Justin Richer  wrote:

> I believe this correction is valid, though I think that the changing of a
> normative requirement is beyond an erratum.
>
> Ultimately, though, this comes down to the definition of what "a client"
> is, which is pretty fuzzy in OAuth. The AS needs to be able to issue the
> same identifier to what it feels is an instance of the same client
> software, if it wants to do that. You can think of these instances as
> different clients in a way, which is what the ’SHOULD NOT’ was for.
> However, if you contend that these instances are "the same client" then the
> 'MUST NOT' makes sense.
>
> In the end, I’m not sure how much difference this change would actually
> make for implementations, because of the fuzziness around the definitions.
> I’m hopeful that some of the new language in OAuth 2.1 around client types
> and instances and registration will help settle this and we can call things
> something consistent.
>
> As such, I’m on the fence whether we should accept or reject the erratum —
>
>  - if we accept, that’s a normative change, but not likely to affect other
> implementations (especially those that implement the OIDC version already)
>  - if we reject, we obviously don’t change implementations but we also
> keep carrying this ambiguity forward
>
>  — Justin
>
> > On Jan 25, 2024, at 1:25 AM, RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
> >
> > The following errata report has been submitted for RFC7591,
> > "OAuth 2.0 Dynamic Client Registration Protocol".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7782
> >
> > --
> > Type: Technical
> > Reported by: Tim Würtele 
> >
> > Section: 3.2.1
> >
> > Original Text
> > -
> > client_id
> >  REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
> >  currently valid for any other registered client, though an
> >  authorization server MAY issue the same client identifier to
> >  multiple instances of a registered client at its discretion.
> >
> > Corrected Text
> > --
> > client_id
> >  REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
> >  currently valid for any other registered client, though an
> >  authorization server MAY issue the same client identifier to
> >  multiple instances of a registered client at its discretion.
> >
> > Notes
> > -
> > Allowing the same client_id for multiple clients is a contradiction to:
> >
> > 1. This document, Section 1.3, (D), 2nd bullet point: "a client
> identifier that is unique at the server"
> >
> > 2. This document, Section 3.1: "The authorization server assigns this
> client a unique client identifier"
> >
> > 3. (normative reference) RFC 6749, Section 2.2: "The authorization
> server issues the registered client a client identifier -- a unique string
> representing the registration information provided by the client. [...] The
> client identifier is unique to the authorization server."
> >
> > 4. (non-normative reference) OpenID Connect Dynamic Client Registration
> 1.0 incorporating errata set 2, Section 2: "Clients have metadata
> associated with their unique Client Identifier at the Authorization
> Server."; Section 3.1: "The Authorization Server assigns this Client a
> unique Client Identifier"; Section 3.2: "client_id REQUIRED. Unique Client
> Identifier. It MUST NOT be currently valid for any other registered Client.
> "
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7591 (draft-ietf-oauth-dyn-reg-30)
> > --
> > Title   : OAuth 2.0 Dynamic Client Registration Protocol
> > Publication Date: July 2015
> > Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak,
> P. Hunt
> > Category: PROPOSED STANDARD
> > Source  : Web Authorization Protocol
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
>
> ___
> 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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-status-list-01.txt

[Tom Jones]

I think the proposal should be renamed as optimized data mining. AIs around
the world will love the idea. Herd privacy is utter nonsense and has been
from the beginning.

On Tue, Feb 6, 2024, 5:08 AM Denis  wrote:

> Comments on draft-ietf-oauth-status-list-01.txt
>
> The text states:
>
> *11.* *Privacy Considerations*
>
> * 11.1.Issuer tracking and Herd Privacy*
>
> The main privacy consideration for a Status List, especially in the
> context of the *Issuer-Holder-Verifier model,*
> is to prevent the Issuer from tracking the usage of the Referenced Token
> when the status is being checked.
>
> However, the Issuer-Holder-Verifier model is not defined in this document.
>
> A description existed in “draft-ietf-oauth-selective-disclosure-jwt”, but
> this I-D has expired which means that this I-D cannot be referenced any
> more.
> The past definition for a Holder in this I-D was:
>
> Holder:  An entity that received SD-JWTs (2.1) from the issuer and has
> control over them.
>
> In this past definition, the use of the word “entity” was not crystal
> clear. There is a need to indicate that *a Holder is an **application*
> under the control of an *individual *and that some choices will done by
> the Holder (application) but also by the individual using that application,
> in particular choices and consents from the individual. An alternative
> definition would be:
>
> Holder: Software application running on a device or on hardware that
> manages digital credentials under the control of an individual.
>
> The original "3 roles model" was described in the VCDM 1.0 document from
> the W3C. It was only a "Data Model" for two (important) pieces of data.
>
> In order to build protocols for the “Issuer-Holder-Verifier model”, a
> threat analysis should first be done on this model.
> Unfortunately, this has not yet been the case. Such analysis would lead to
> identify security properties and privacy properties
> that may be desirable to be met. This would have allowed to build one or
> more architectures using a “privacy and security by design” approach.
>
> Among various properties, two privacy properties that apply to the 3
> roles model are: “Unlinkability between verifiers “ and “Untrackability by 
> digital
> credential issuers”:
>
> “*Unlinkability **between verifiers*” means that two verifiers should not
> be able to know whether two digital proofs are presented by the same
> individual.
>
> “*Untrackability **by* *digital credential issuers*” means that a digital
> credential issuer should not be able to know to which verifiers a digital
> credential
>  that it has issued to a Holder, or derivations from it, will be presented.
>
> The current approach is driven by a CRL-like mechanism proposal. This is
> only a part of a puzzle that might be belong to a wider picture,
> but, before, it would be better to know how the whole picture looks like.
> Instead of a bottom-up approach, a top-down approach would be preferable.
>
> The current approach is considering the case where the “non-revoked”
> status of a digital credential would be obtained by the verifier.
> This is a “verifier centric” approach.
>
> Another approach would be to consider that it is not the job of the
> verifiers to check the “non-revoked” status of the digital credentials they
> verify,
> but that it is the job of the Holder (application). This would be a
> “Holder centric” approach.
>
> The Holder (application) needs to be a Trusted Application (TA) that can
> be trusted by the digital credential issuer to effectively control
> and limit the use of some cryptographic keys and that cannot be modified
> by an individual. A “digital identity wallet” is the prime example of a TA.
>
> In the real-life, a “*digital identity wallet*” is supported by a smart
> phone or a tablet which will usually be online as soon as some network is
> locally available.
>
> When a digital credential is requested by a Holder at the initiative of an
> individual, the base URL of the digital credential issuer needs to be
> provided.
> Such base URL can be built-in the downloaded Holder (application), added
> when a revision of that Holder (application) is available or manually
> entered by the individual.
>
> An access point to contact the digital credential issuer can be derived
> from the base URL of the digital credential issuer.
> Once a digital credential has successfully been downloaded by the Holder,
> this access point can be used by the Holder to dialogue with the digital
> credential issuer
> as soon as the smart phone or tablet is online.
>
> During this dialogue, if some entity asked to a digital credential issuer
> the revocation or the suspension of a digital credential still within its
> validity period,
> the digital credential issuer can freeze (i.e. suspend) the use of that
> digital credential. A policy may be put in place to say that if no contact
> has been possible
> with a digital credential issuer during some period of time, the use of
> each digital

Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[Tom Jones]

Not sure if techies care, but that really needs to be a four party
transaction where the subject of a credential may not be the holder of the
device where the credential is held. Your are thereby excluding
appropriately 15% of humanity. This is, frankly, unconscionable and you
must accommodate all humans who are likely to need digital credentials.

thx ..Tom (mobile)

On Fri, Feb 9, 2024, 11:06 AM Roman Danyliw  wrote:

> Forwarding to raise awareness.  Please provide feedback on the SPICE
> charter by Thursday, February 22 by using the spice@ietf mailing list (
> https://www.ietf.org/mailman/listinfo/spice).  This consensus thread
> starts here:
> https://mailarchive.ietf.org/arch/msg/spice/TTgOt6qI3CzILzV4i34nLmkmeMc/.
>
> -Original Message-
> From: SPICE  On Behalf Of Roman Danyliw
> Sent: Friday, February 9, 2024 2:01 PM
> To: sp...@ietf.org
> Subject: [SPICE] Call for consensus on SPICE charter
>
> Hi!
>
> At IETF 118, a BoF on SPICE was convened [1].  The meeting provided a
> strong consensus signal that there was a problem to solve and that the IETF
> was the right place to do that.  While there was enthusiasm around the
> topic, there was strong feedback the scope of the work needed refinement.
>
> In recent months, there have been numerous follow-on discussion and
> refinement on the charter text.  As we approach final planning for IETF
> 119, I'd like to assess where we stand with a formal consensus check on a
> revised charter responsive to the feedback during the IETF 118 BoF.  Please
> see https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/ (00-00)
> and respond to the list by Thursday, February 22 (two weeks from now):
>
> ==[ start consensus check questions ]==
> (1) Do you support the charter text? Or do you have objections or blocking
> concerns (please describe what they might be and how you would propose
> addressing the concern)?
>
> If you do support the charter text:
> (2) Are you willing to author or participate in the developed of the WG
> drafts?
>
> (3) Are you willing to review the WG drafts?
>
> (4) Are you interested in implementing the WG drafts?
>
> ==[ end consensus check questions ]==
>
> If you previously spoke up at the BoF, please repeat yourself here.
> Earlier versions of a charter were shared on the mailing list and informal
> inquiries of support were requested.  Please repeat your support or
> concerns for this 00-00 charter even if you commented on earlier iterations.
>
> The outcome of this consensus check will inform how to plan for the second
> SPICE BoF scheduled at IETF 118.  Non-exhaustive options include:
>
> (a) If we find consensus on the mailing with the current charter text, no
> BoF is needed, and it will be canceled.  Note, this should be viewed as a
> success.  The entire point of the BoF is to produce and find consensus on a
> charter and that goal would have been realized.  SPICE proponents have
> indicated a side meeting will be held.
>
> (b) If there are blocking concerns which cannot be resolved on the mailing
> list, these will form the basis of the IETF 118 BoF agenda
>
> A common question I've already gotten is can SPICE be a WG by IETF 119.
> The simple answer is no -- there is insufficient time to perform all of the
> necessary review steps before IETF 119 to charter SPICE.  In more detail,
> assume hypothetically that there is unbridled enthusiasm for the work from
> the community and IESG: this email consensus check takes 2 weeks (till Feb
> 22) + 1 week advanced notice before an IESG formal telechat for initial
> review + initial IESG review (on Feb 29) + 10 days for community review + a
> return back for final IESG approval at a formal telechat.The last
> formal IESG telechat is March 7 (which is before the community review
> period would close).  In the best case by IETF 119, this charter would have
> been through initial IESG review, all community feedback would have been
> adjudicated, and the charter would be waiting discussion at the first
> formal IESG telechat after the IETF 119 meeting.
>
> As a process matter, options (a) and (b) are both hypothetical options
> pending the results of this call for consensus.  However, I'd like to be
> sensitive to earlier feedback on my use of option-(a) for the last  WG
> chartered out of SEC, KEYTRANS.  In the lead up to IETF 118, option-(a) was
> exercised for the planned KEYTRANS BOF (i.e., it was canceled) because
> consensus was found on the mailing list and sent to the IESG before the
> meeting.  There was community feedback that canceling the BOF denied an
> opportunity to provide feedback that was being saved for the F2F BoF and
> missed a F2F opportunity to gather interested parties.  To that end, I will
> be cross posting this call for consensus on SPICE to SAAG and identity
> adjacent WG lists (e.g., JOSE, COSE, SCITT, OAuth, RATS) to ensure broad
> awareness of this call.  SPICE proponents have signaled to me that they
> would organize a side meeting if the BoF is

Re: [OAUTH-WG] Type Metadata for SD-JWT VC

[Tom Jones]

So now we are proposing types of types of types of data elements. I feel
really bad about this as I introduced the first semantic tag into EDI back
in the 1980s. I can't believe it has come to this. I can't believe that
anyone imagines giving this sort of specification to different programmers
and expecting interoperability. There must be a better way!

thx ..Tom (mobile)

On Wed, Apr 3, 2024, 12:22 AM Daniel Fett  wrote:

> Hi all,
>
> as discussed during IETF 119, we would like to introduce what we call Type
> Metadata to SD-JWT VC.
>
> For a bit of context, the intention is to provide a mechanism to provide
> information about credential types (e.g., a JSON schema, display/rendering
> information, a name and description to be used by developers, etc.). Type
> Metadata can be organized in a hierarchical structure using "extends"
> relationships.
>
> The need for such a mechanism developed from discussions around the 'vct'
> (Verifiable Credentials Type) identifier
>  in SD-JWT VC and
> again in the context of the EUDI Wallet
> .
>
> I drafted a first tentative design in this specification
> 
> and we now want to revisit that and start moving pieces of that over to
> SD-JWT VC.
>
> The first PR 
> introduces the basic Type Metadata structures including the extension and
> integrity protection mechanisms. It lacks many of the features we would
> like to see in an MVP, so we plan to release a new draft only after
> introducing a few more features
>  in follow-on PRs.
>
> We would like to invite you to review the PR and let us know if there is
> any feedback! I also plan to discuss this in more detail at an unconference
> session at the OAuth Security Workshop.
>
> -Daniel, Brian, Oliver
>
>
> ___
> 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

Re: [OAUTH-WG] [SPICE] SPICE Revocation

[Tom Jones]

There is a huge hole here. Revocation of (for example) driving privileges
should not impact the use of the cred for other purposes. The revocation
idea can lead to cancelation of the person. Some that violates the
fundamental rights of human beings. Revocation is basically discrimination.

thx ..Tom (mobile)

On Fri, Mar 29, 2024, 2:50 AM Denis  wrote:

> This thread is related to the three roles model, i.e, Holder, Issuer and
> Verifier.
> However, I also copy this email to the OAuth WG, since it is currently
> developing draft-ietf-oauth-status-list.
>
> Thanks to Orie for providing the second link:
>
> https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept/-/blob/main/architecture-proposal.md?ref_type=heads#ocsp-stapling
> .
>
> What first follows a copy/paste of some parts of the "Architecture
> Proposal for the German eIDAS Implementation". Then after, my observations
> follow.
>
> Various use cases and scenarios may require revocation:
>
>- the PID/(Q)EAA Provider wants to revoke its issued credential
>because the contained data is no longer valid
>- the Wallet Provider wants to revoke a Wallet Instance because Wallet
>Security Cryptographic Device (WSCD)
>or the Wallet Instance application is compromised or vulnerable
>- the user wants to revoke their Wallet Instance because they lost
>their smartphone
>- the user wants to revoke their PID
>- the PID Provider wants to revoke a PID because the person has died
>
> To enable revocation within the EUDI Wallet ecosystem, the following
> mechanisms for revocation are considered:
>
> (a) Certificate Revocation Lists
> (b) Status Lists
> (c) Online Certificate Status Protocol (OCSP)
> (d) OCSP stapling
>
> *My observations:*
>
> For case (a): "CRLs have seen some scalability limitations in the Browser
> TLS context, and
>   it remains open to evaluate if CRL sizes remain
> manageable within the eIDAS ecosystem".
>
> For case (b): "it remains open to evaluate if this is sufficient for the
> eIDAS ecosystem".
>
> For case (c): "Therefore, usage of OSCP is *not* recommended".
>
> For case (d): "a proposal applying the concepts to the PID credential
> formats is under development
> .
> [i.e., draft-demarco-oauth-status-attestations-00]
> the concept has the privacy potential as the Relying Party does not fetch
> the revocation information itself".
>
> draft-demarco-oauth-status-attestations-00 looks interesting.
>
> Presently, this draft does not include a privacy considerations section.
> It is thus questionable whether it is able to support the unlinkability
> property
> [it cannot be distinguished whether two transactions are related to the
> same user or not].
>
> Some nice characteristics are :
>
>- "the Relying Party does not fetch the revocation information
>itself".
>- "both the wallet and the verifier work without internet connectivity
>during the presentation phase".
>
> But what about a mechanism where, in addition, the holder does not fetch
> the revocation information itself ?
> Yes, neither the holder, nor the verifier, fetch itself any revocation
> information.
>
>
>
> Is it "mission impossible"? No, it isn't.
>
>
>
> A Wallet Provider is in a position to suspend (i.e., which is equivalent
> to a temporary revocation) any digital credential placed in a Wallet
> Instance.
> It is also in a position to invalidate the use of a Wallet Instance or to
> remove any digital credential placed in a Wallet Instance (which is
> equivalent
> to a definitive revocation).
>
> A Wallet instance is THE Holder, i.e., an application that needs to be a
> Trusted Application (TA) running in a TEE. Every time the holder
> (application)
> is online, it can transparently connect to the Wallet Provider. If
> instructed by a Credential Issuer, a Wallet Provider can suspend any
> digital credential
> issued by that Credential Issuer.
>
> The digital credentials placed in a Wallet Instance will only be usable if
> the Wallet Instance has been online during, e.g., the last 24 or 36 hours.
>
> From a holder point of view (or a Wallet Instance point of view), each
> time it is online, it will connect to its Wallet Provider.
> If no digital credential needs to be suspended, then all the digital
> credentials will be usable during the next 24 or 36 hours, but no longer.
> The query made by the Wallet Instance to its Wallet Provider can be
> transparently repeated, e.g., every hour. If a suspension is requested
> by a Credential Issuer while the Wallet Instance is online, the suspension
> will occur at latest within, e.g., the next hour.
>
> The same mechanism can also be used to revoke the Wallet Instance when the
> individual lost his smart phone.
> All the other approaches would require the revocation (or the suspension)
> of each digital credential, one by one.
>
> This approach avoids to define new data structures

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Tom Jones]

Y'all are missing another option. (re Sam's Comments)
The user is given a user agent to use on their own device when accessing
enterprise data.
I know of two that are shipping today. https://www.getprimary.com/
Now it is possible to access other sites with these browsers as well - in
fact they specifically support sites like github in such a way to get
enterprise creds.
Perhaps we need to test these mechanisms with those user agents?
Is it helpful if i asked them for feedback - when this gets to blink they
will see them then as they are chromium forks.
That might cause them to change the FedCM code.

Interested in the problem of multiple IdPs.  I run three different browsers
now just to deal with that problem.

Relying parties accept different IdP?   that sux.  I want to decide who
I am based on the circumstances!!

..tom


On Wed, May 8, 2024 at 2:02 PM Sam Goto 
wrote:

>
>
> On Wed, May 8, 2024 at 2:01 PM Joseph Heenan  wrote:
>
>>
>>
>> On 8 May 2024, at 21:43, Sam Goto  wrote:
>>
>>
>>
>> On Wed, May 8, 2024 at 1:34 PM Joseph Heenan  wrote:
>>
>>> Hi Neil
>>>
>>>
>>> On 8 May 2024, at 18:45, Neil Madden  wrote:
>>>
>>>
>>> On 8 May 2024, at 17:52, Sam Goto  wrote:
>>>
>>> On Wed, May 8, 2024 at 7:23 AM Neil Madden 
>>> wrote:
>>>
>>>
>>>
>>>
 In particular, the call to the accounts endpoint assumes that the IdP
 is willing to provide PII about the user to the browser. That seems
 questionable.

>>>
>>> Aside from a privacy/security threat model perspective (meaning, the
>>> user agent already has visibility over every network request made available
>>> to the content area)
>>>
>>>
>>> Sure, but if I use the recommended auth code flow or encrypted ID
>>> tokens, then PII is not exposed to the browser. And it’s not just the
>>> browser itself in the current proposal, as the token is exposed to
>>> javascript, of course, so the usual XSS risks.
>>>
>>>
>>> Sam’s response here is fair, but also note that as far as I understand
>>> it you can still use the authorization code flow or encrypted id tokens
>>> with the FedCM API
>>>
>>
>> That's correct: the browser doesn't open the response from the IdP to the
>> RP, so it can, for example, be encrypted.
>>
>> I was assuming that Neil was referring to the fact that the
>> id_assertion_endpoint (which contains the user's IdP's PII accounts
>> )
>> become, suddenly, transparent to the browser.
>>
>>
>> Oh yes, that’s true - but (I think) the data from the
>> id_assertion_endpoint at least isn’t exposed to javascript and isn’t
>> vulnerable to XSS?
>>
>
> That's correct.
>
>
>>
>> Joseph
>>
>> ___
> 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

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Tom Jones]

Right. Google treats email as a guid for user name. Any old guid should
work.

thx ..Tom (mobile)

On Sat, May 11, 2024, 3:22 PM Dick Hardt  wrote:

>
>
> On Wed, May 8, 2024 at 4:07 PM Sam Goto 
> wrote:
>
>> That's easier to answer: the browser needs name/email/picture to
>> construct an account chooser
>> ,
>> which is the UX that tested best with users by a far margin.
>>
>
>
> I bring up again the issue I filed
> https://github.com/fedidcg/FedCM/issues/242
>
> Registration and login are conflated in OIDC. showing the
> name/email/picture implies those will be shared. That is commonly what
> happens when using Google -- but other IdP's might have those attributes,
> and it may not be what an RP needs, breaking the Law of Identity about
> minimal disclosure.
>
> The FedCM architecture works well to solve the 3P cookie deprecation for
> fancy Google login flow -- but standardizing that as how all login works
> normalizes that email, name, and picture will always be shared -- not a
> goal I think many of us are aligned on.
>
>
>
> ___
> 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

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Tom Jones]

Has anyone considered what information the RP verifier should supply for
FedCM to function well on the behalf of both the verifier and the user?

thx ..Tom (mobile)

On Thu, May 9, 2024, 8:06 AM Dick Hardt  wrote:

> The NASCAR problem is rooted in the RP does not know which provider(s) the
> user has, so sites showed all the choices. FedCM only shows the provider(s)
> the user has.
>
> On Thu, May 9, 2024 at 5:33 AM Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
>> I think I'm still missing something, and I'm sure it was discussed
>> somewhere and I just didn't see it. How will this help avoid the NASCAR
>> problem, for sites when a user *signs up* or when the user *signs in on
>> a new browser?*
>>
>> On Thu, May 9, 2024 at 1:07 AM Sam Goto 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 8, 2024 at 3:50 PM Neil Madden 
>>> wrote:
>>>
 On 8 May 2024, at 22:01, Joseph Heenan  wrote:


 On 8 May 2024, at 21:43, Sam Goto  wrote:



 On Wed, May 8, 2024 at 1:34 PM Joseph Heenan 
 wrote:

> Hi Neil
>
>
> On 8 May 2024, at 18:45, Neil Madden  wrote:
>
>
> On 8 May 2024, at 17:52, Sam Goto  wrote:
>
> On Wed, May 8, 2024 at 7:23 AM Neil Madden 
> wrote:
>
>
>
>
>> In particular, the call to the accounts endpoint assumes that the IdP
>> is willing to provide PII about the user to the browser. That seems
>> questionable.
>>
>
> Aside from a privacy/security threat model perspective (meaning, the
> user agent already has visibility over every network request made 
> available
> to the content area)
>
>
> Sure, but if I use the recommended auth code flow or encrypted ID
> tokens, then PII is not exposed to the browser. And it’s not just the
> browser itself in the current proposal, as the token is exposed to
> javascript, of course, so the usual XSS risks.
>
>
> Sam’s response here is fair, but also note that as far as I understand
> it you can still use the authorization code flow or encrypted id tokens
> with the FedCM API
>

 That's correct: the browser doesn't open the response from the IdP to
 the RP, so it can, for example, be encrypted.

 I was assuming that Neil was referring to the fact that the
 id_assertion_endpoint (which contains the user's IdP's PII accounts
 )
 become, suddenly, transparent to the browser.


 Oh yes, that’s true - but (I think) the data from the
 id_assertion_endpoint at least isn’t exposed to javascript and isn’t
 vulnerable to XSS?


 That depends on whether the IdP correctly enforces the presence of the
 sec-fetch-dest header. If it doesn’t then yes, it would be vulnerable.
 Presumably it’s also vulnerable on older/niche browsers that don’t block
 sec-* headers: caniuse.com reckons > 8% of users globally are using
 browsers that don’t understand any sec-fetch-* headers. I’m not sure when
 sec-* was added to the forbidden list.

 I guess, flipping this around, we might ask what is the legitimate
 purpose for which browsers need to access the user’s name, email address
 (both requires) and other identifying information? I’d have thought an
 identifier (possibly randomised) and some user-supplied account nickname
 would be sufficient.

>>>
>>> That's easier to answer: the browser needs name/email/picture to
>>> construct an account chooser
>>> ,
>>> which is the UX that tested best with users by a far margin.
>>>
>>> Static/unpersonalized permission prompts - example
>>>  in
>>> Safari, example
>>> 
>>> in Chrome - perform extremely poorly (in comparison to account choosers),
>>> although have other benefits too (namely ergonomics and extensibility), so
>>> Chrome (and others) expose that too in the form of the Storage Access
>>> API
>>> .
>>>
>>>

 — Neil

 ___
>>> 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
>>
> ___
> 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

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Tom Jones]

Here is an alternate proposal which just addresses JUST the information
that is needed to establish trust between the verifier and the user.
Somehow all of the other proposals come with decades of history that is
only slightly interesting going forward.

https://docs.google.com/document/d/1n7HobJ6QTsNld5rn1uuIiNw0A__L44ug/edit?usp=sharing&ouid=109794657323597753486&rtpof=true&sd=true
..tom



On Thu, May 9, 2024 at 10:01 AM Sam Goto  wrote:

>
>
> On Thu, May 9, 2024 at 9:07 AM Tom Jones 
> wrote:
>
>> Has anyone considered what information the RP verifier should supply for
>> FedCM to function well on the behalf of both the verifier and the user?
>>
>
> Can you expand on this a bit more? Selective disclosure came to mind to us
> (e.g. an RP selectively asking for specific attributes), but maybe you have
> something else in mind?
>
>
>>
>> thx ..Tom (mobile)
>>
>> On Thu, May 9, 2024, 8:06 AM Dick Hardt  wrote:
>>
>>> The NASCAR problem is rooted in the RP does not know which provider(s)
>>> the user has, so sites showed all the choices. FedCM only shows the
>>> provider(s) the user has.
>>>
>>> On Thu, May 9, 2024 at 5:33 AM Warren Parad >> 40rhosys...@dmarc.ietf.org> wrote:
>>>
>>>> I think I'm still missing something, and I'm sure it was discussed
>>>> somewhere and I just didn't see it. How will this help avoid the NASCAR
>>>> problem, for sites when a user *signs up* or when the user *signs in
>>>> on a new browser?*
>>>>
>>>> On Thu, May 9, 2024 at 1:07 AM Sam Goto >>> 40google@dmarc.ietf.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 8, 2024 at 3:50 PM Neil Madden 
>>>>> wrote:
>>>>>
>>>>>> On 8 May 2024, at 22:01, Joseph Heenan  wrote:
>>>>>>
>>>>>>
>>>>>> On 8 May 2024, at 21:43, Sam Goto  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, May 8, 2024 at 1:34 PM Joseph Heenan 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Neil
>>>>>>>
>>>>>>>
>>>>>>> On 8 May 2024, at 18:45, Neil Madden 
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 8 May 2024, at 17:52, Sam Goto  wrote:
>>>>>>>
>>>>>>> On Wed, May 8, 2024 at 7:23 AM Neil Madden 
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> In particular, the call to the accounts endpoint assumes that the
>>>>>>>> IdP is willing to provide PII about the user to the browser. That seems
>>>>>>>> questionable.
>>>>>>>>
>>>>>>>
>>>>>>> Aside from a privacy/security threat model perspective (meaning, the
>>>>>>> user agent already has visibility over every network request made 
>>>>>>> available
>>>>>>> to the content area)
>>>>>>>
>>>>>>>
>>>>>>> Sure, but if I use the recommended auth code flow or encrypted ID
>>>>>>> tokens, then PII is not exposed to the browser. And it’s not just the
>>>>>>> browser itself in the current proposal, as the token is exposed to
>>>>>>> javascript, of course, so the usual XSS risks.
>>>>>>>
>>>>>>>
>>>>>>> Sam’s response here is fair, but also note that as far as I
>>>>>>> understand it you can still use the authorization code flow or 
>>>>>>> encrypted id
>>>>>>> tokens with the FedCM API
>>>>>>>
>>>>>>
>>>>>> That's correct: the browser doesn't open the response from the IdP to
>>>>>> the RP, so it can, for example, be encrypted.
>>>>>>
>>>>>> I was assuming that Neil was referring to the fact that the
>>>>>> id_assertion_endpoint (which contains the user's IdP's PII accounts
>>>>>> <https://fedidcg.github.io/FedCM/#dictdef-identityprovideraccount>)
>>>>>> become, suddenly, transparent to the browser.
>>>>>>
>>>>>>
>>>>>> Oh yes, th

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Tom Jones]

Question - how does all this interact with the password manager?
Can the RP ask if they have an entry in the PM first? Or is that too much
of a privacy issue?

Also when calling for an app, wouldn't it matter if the app were web vs
native?
Which one does this thread discuss? ..tom


On Tue, May 21, 2024 at 1:47 PM Dick Hardt  wrote:

> Yes, IdP chaining is common.
>
> In your example acme.com is an RP to all the federated IdPs — and
> gathering the identifier to determine the IdP is out of scope of federation
> protocols.
>
> On Thu, May 9, 2024 at 9:54 AM Brock Allen  wrote:
>
>> Could be, but if the IdP the RP uses is itself a gateway to other IdPs
>> then this might not work (especially if they're all cross-site).
>>
>> I have a real world use case as an example for a customer (let's call
>> them "Acme"). They have many RPs, one of which might be at acme.ca.
>> Since they have so many RPs, they have designed a central IdP for all of
>> Acme and that resides at login.acme.com (notice cross-site). Employees
>> and business partners login via the central Acme IdP, but the business
>> partners' credentials are held at the business partner IdP, thus those
>> users are federating.
>>
>> Now a user from business partner "Wonka" needs to use the RP at acme.ca.
>> To login they are redirected to login.acme.com. During this process at
>> login.acme.com, the user is prompted in some way to determine that they
>> are a Wonka employee and really need to use wonka.com as the ultimate
>> IdP. They then are redirected to Wonka to actually enter credentials and
>> login. The trust relationship is that RP trusts Acme IdP, which in turn
>> trusts Wonka IdP (all three of which are cross site).
>>
>> Oh and also... at some point the user needs to logout :)
>>
>> So perhaps a more complicated example than most, but this is exactly what
>> many organizations are doing today with OAuth and OIDC.
>>
>> Again, hope this makes sense.
>>
>>
>> -Brock
>>
>> On 5/9/2024 12:36:28 PM, Dick Hardt  wrote:
>> Would that identifier first flow not just be part of the app? The app
>> gets the identifier and then knows which IdP (if any) to redirect the user
>> to.
>>
>> On Thu, May 9, 2024 at 9:06 AM Brock Allen  wrote:
>>
>>> Often a user needs to be presented with a prompt collecting some data to
>>> identity the upstream IdP (e.g. email, or something else). This is very
>>> common with B2B relationships. This is in lieu of showing a long list of
>>> the IdP (NASCAR) buttons because perhaps you, as a business, don't want to
>>> show off all the business partners you integrate with for SSO.
>>>
>>> Hope that makes sense.
>>>
>>> -Brock
>>>
>>> On 5/9/2024 12:04:13 PM, Dick Hardt  wrote:
>>> Would you elaborate on your point Brock? I don’t follow.
>>>
>>> On Thu, May 9, 2024 at 8:54 AM Brock Allen  wrote:
>>>
 This is why redirects with a custom UI are so essential. This allows
 other forms of HRD without a NASCAR button list too. I hope that this will
 remain possible, as it's crucial to so many business use cases.


 -Brock

 On 5/9/2024 11:06:23 AM, Dick Hardt  wrote:
 The NASCAR problem is rooted in the RP does not know which provider(s)
 the user has, so sites showed all the choices. FedCM only shows the
 provider(s) the user has.

 On Thu, May 9, 2024 at 5:33 AM Warren Parad >>> 40rhosys...@dmarc.ietf.org> wrote:

> I think I'm still missing something, and I'm sure it was discussed
> somewhere and I just didn't see it. How will this help avoid the NASCAR
> problem, for sites when a user *signs up* or when the user *signs in
> on a new browser?*
>
> On Thu, May 9, 2024 at 1:07 AM Sam Goto  40google@dmarc.ietf.org> wrote:
>
>>
>>
>> On Wed, May 8, 2024 at 3:50 PM Neil Madden 
>> wrote:
>>
>>> On 8 May 2024, at 22:01, Joseph Heenan  wrote:
>>>
>>>
>>> On 8 May 2024, at 21:43, Sam Goto  wrote:
>>>
>>>
>>>
>>> On Wed, May 8, 2024 at 1:34 PM Joseph Heenan 
>>> wrote:
>>>
 Hi Neil


 On 8 May 2024, at 18:45, Neil Madden 
 wrote:


 On 8 May 2024, at 17:52, Sam Goto  wrote:

 On Wed, May 8, 2024 at 7:23 AM Neil Madden 
 wrote:




> In particular, the call to the accounts endpoint assumes that the
> IdP is willing to provide PII about the user to the browser. That 
> seems
> questionable.
>

 Aside from a privacy/security threat model perspective (meaning,
 the user agent already has visibility over every network request made
 available to the content area)


 Sure, but if I use the recommended auth code flow or encrypted ID
 tokens, then PII is not exposed to the browser. And it’s not just the
 browser itself in the current proposal, as the token is exposed to

[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones]

This whole problem did not need to happen. When the federation spec was
being created I asked them not to deviate unnecessarily from pki. But the
very guys that are on this thread told me that they were not a pki and so
there was no reason for them to follow existing rules. This is entirely a
problem of there own making. So let them fix their own mistakes.

thx ..Tom (mobile)

On Mon, Jun 10, 2024, 8:37 PM Watson Ladd  wrote:

> On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
>  wrote:
> >
> > We all know that TLS certificates are handled by platform layers used by
> applications and not the applications themselves.  There is no code that
> understands X.509 certificates in most applications that use TLS.  They are
> not equivalent in complexity.
> >
> >
> >
> > The draft would require adding code directly understanding the structure
> and fields of X.509 to applications using it.  Eliminate that, and I’ll
> support adoption.
>
> I don't understand your proposal. An X509 certificate is the only way
> to link a DNS name to a key at a given point in time as we can
> leverage the Web PKI. Absent that, what do you do?
>
> Also, I'm not sure what you mean by platform layers. Many of them
> expose a function to verify a signature with a key in an X509 cert or
> verify a cert chain, even outside the context of TLS. Are there
> particular ones that would have a problem you are concerned about?
>
> Sincerely,
> Watson Ladd
>
> ___
> 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

[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones]

he opportunity to work
>>> together in this field
>>>
>>> Il giorno mer 12 giu 2024 alle ore 12:47 Rohan Mahy <
>>> rohan.m...@gmail.com> ha scritto:
>>>
>>>> Giuseppe,
>>>> Given that verifying the issuer is already done using X.509 PKI today,
>>>> why do you object to trusting the PKI root for the same purpose (validating
>>>> the domain name of the issuer) with the same validity period (between the
>>>> notBefore and notAfter of the certificate)?
>>>>
>>>> Thanks,
>>>> -rohan
>>>>
>>>> On Tue, Jun 11, 2024 at 4:44 AM Giuseppe De Marco 
>>>> wrote:
>>>>
>>>>> Ciao Tom,
>>>>>
>>>>> Public Key Infrastructure satisfies the requirements to provide public
>>>>> keys. Technically, using X.509 certificates represents a consolidated
>>>>> approach.
>>>>> Giving public keys doesn't help in establishing the trust or fully
>>>>> proving the compliance to shared rules, that's why openid federation
>>>>> authors insist that openid federation is not only a pki.
>>>>>
>>>>> TLS is not removed, we use X.509 based pki on the web, therefore also
>>>>> using federation.
>>>>>
>>>>> TLS is used to establish confidentiality with an endpoint,
>>>>> establishing trust to a subject only because it controls a private
>>>>> cryptographic key is similar to the weakness about the bearer tokens.
>>>>> Therefore, for instance, in advanced ecosystems and implementation is
>>>>> required to demonstrate the proof of possession of the tokens because
>>>>> bearers alone are not secure enough. This is more complex but required in
>>>>> the real wold.
>>>>>
>>>>> The point is: what is trust, how to establish trust in the real world,
>>>>> which are the technical layers that we should (even in a modular way) take
>>>>> into account to achieve our goals. Do we have the same goals?
>>>>> Don't stop working together, let's keep the conversation to achieve
>>>>> our goals in an harmonic way.
>>>>>
>>>>> Il giorno mar 11 giu 2024 alle ore 06:11 Tom Jones <
>>>>> thomasclinganjo...@gmail.com> ha scritto:
>>>>>
>>>>>> This whole problem did not need to happen. When the federation spec
>>>>>> was being created I asked them not to deviate unnecessarily from pki. But
>>>>>> the very guys that are on this thread told me that they were not a pki 
>>>>>> and
>>>>>> so there was no reason for them to follow existing rules. This is 
>>>>>> entirely
>>>>>> a problem of there own making. So let them fix their own mistakes.
>>>>>>
>>>>>> thx ..Tom (mobile)
>>>>>>
>>>>>> On Mon, Jun 10, 2024, 8:37 PM Watson Ladd 
>>>>>> wrote:
>>>>>>
>>>>>>> On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
>>>>>>>  wrote:
>>>>>>> >
>>>>>>> > We all know that TLS certificates are handled by platform layers
>>>>>>> used by applications and not the applications themselves.  There is no 
>>>>>>> code
>>>>>>> that understands X.509 certificates in most applications that use TLS.
>>>>>>> They are not equivalent in complexity.
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > The draft would require adding code directly understanding the
>>>>>>> structure and fields of X.509 to applications using it.  Eliminate that,
>>>>>>> and I’ll support adoption.
>>>>>>>
>>>>>>> I don't understand your proposal. An X509 certificate is the only way
>>>>>>> to link a DNS name to a key at a given point in time as we can
>>>>>>> leverage the Web PKI. Absent that, what do you do?
>>>>>>>
>>>>>>> Also, I'm not sure what you mean by platform layers. Many of them
>>>>>>> expose a function to verify a signature with a key in an X509 cert or
>>>>>>> verify a cert chain, even outside the context of TLS. Are there
>>>>>>> particular ones that would have a problem you are concerned about?
>>>>>>>
>>>>>>> Sincerely,
>>>>>>> Watson Ladd
>>>>>>>
>>>>>>> ___
>>>>>>> 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
>>>>>>
>>>>> ___
>>>>> 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

[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

[Tom Jones]

I am utterly appalled by this statement
" opaque value, OAuth implementors usually don't sanitize the value."
No web site should ever use any data from the user's device without full
validation as it is *completely untrustworthy*.
Treating this head value differently than any other header value is WRONG.
NONE is trustworthy.
Be the change you want to see in the world ..tom


On Mon, Jul 1, 2024 at 5:20 AM Chaitanya Reddy <
nchaitreddyutilit...@gmail.com> wrote:

> Hi Team,
>
> Hope you are doing well!
>
> I am writing this mail regarding the discussion of usage of *state*
> parameter in the OAuth implementation.
>
> As per the RFC 6749, "*An opaque value is used by the client to maintain
> state between the request and callback. And it should be used to prevent
> cross-site request forgery*". Since it's an opaque value, OAuth
> implementors usually don't sanitize the value.
>
> One of the OAuth 2.0 implementors (Google) have defined state as "*You
> can use this parameter for several purposes, such as directing the user to
> the correct resource in your application, sending nonces, and mitigating
> cross-site request forgery*"
>
> The issue arries here due to the fact that Google allows the use of state
> parameter for directing the users to the correct resource. Since the value
> in RFC is defined as *opaque, *they are not sanitizing the value for any
> possible malicious values. I have observed two instances where clients
> using Google's OAuth service directly use the state parameter value in 
> *Location
> header *to redirect the users hence resulting in header injection attacks.
>
> As per my understanding, this issue arises due to the fact that:
> 1. Google allows state parameter to be used for purpose not defined in RFC.
> 2. Google is not sanitizing the state paramater on their end.
> 3. Client is also not sanitizing the state paramater and directly using it
> in the *Location* header.
>
> I have raised this issue to google via google VRP but after weeks of
> communication over the ticket, the engineer feels like they are not in
> disagreement with the spec and have requested me to discuss it further with
> your team and hence i am reaching out to you.
>
> Please let me know your thoughts about this.
>
> Regards,
> Chaitanya Reddy
> ___
> 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

[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones]

I have opposed channel-binding or token-binding from the beginning as they
serve very different puppies and typically fall under different management
within large enterprises. I have tried to push for a simple way to test the
validity of a signature for decades into the future as that is typical for
a wet signature. If digital signatures are ever acceptable as a replacement
for wet signatures then longer checking capabilities are required.

thx ..Tom (mobile)

On Wed, Jul 3, 2024, 8:41 AM John Bradley  wrote:

> I am not opposed to adding additional security for JWK key sets.
>
> I, however, share concerns about mixing the layering of certificates for
> transport security and application-level signing.
>
> I am not saying you can’t do it, but it adds operational complexity.
>
> One problem with TLS certificates is they end up living in a lot of places
> like reverse proxies and servers without HSM.
>
> As a result, the lifetime of TLS certificates gets shorter and shorter. I
> believe Letsencrypt is down to 90 days, and that could and perhaps should
> get shorter.
>
> That may not match the operational needs for application-level signing.
> /
> Looking at potential EU trust list requirements the private key used to
> sign the metadata for federation may need to be signed over by multiple
> trust lists (no I don’t think that is a good idea, but when has the EU been
> reasonable?).   I can see lots of interesting operational issues when you
> start combining these things.   Will lets encrypt allow the same private
> key over multiple issuances when it needs to be more or less static to
> match the other certs?
>
> This proposal is interesting but may have unintended and perhaps undesired
> interactions by mixing the layers.
>
> Perhaps there are ways to resolve these issues.
>
> I am happy to discuss further.
>
> Regards
> John B.
>
> On Jul 2, 2024, at 6:40 AM, Pieter Kasselman  40microsoft@dmarc.ietf.org> wrote:
>
> I want to thank the authors for preparing this draft. It addressees an
> important set of scenarios and I am supportive of the goal of this draft to
> add additional protection to JWK Key sets beyond being hosted on a web
> server protected by a TLS connection.
> I have some questions around the trust framework/trust model and would
> like to see some clarification or clear guidance on where the X.509
> certificates would come from and how they would be used. In general I am
> concerned by practices of using the same keys and certs for multiple
> purposes. It causes confusion and may result in security issues.
> From reading the draft and some comments referring to Web PKI, I get the
> impression that one option is to use TLS certs for signing artefacts that
> would be long lived, or would need to be archived/managed for a long time.
> Generally, using a key/cert to authenticate a web server for an ephemeral
> connection is different from generating long lived signatures that may be
> archived for decades as part of security audit data. Even if a separate TLS
> cert is used, it raises concerns about confusion that may result from using
> TLS certs in this way (it would be indistinguishable from a regular TLS
> cert for anyone verifying the key set). If the same certs/keys are used for
> both the TLS connection and generating PIKA proofs, it raises questions
> about application layer access to signing keys on the web server where the
> TLS session gets terminated. TLS keys are by nature closer to the edge
> where they are more accessible/vulnerbale, compared to keys that are used
> to sign artefacts that may persist over time and should be kept further
> away from the edge.
> It would be good to provide clear guidance on the trust framework for PIKA
> certs. where they would come from and the need of keeping them separate
> from certificates and keys used for ephemeral purposes (securing TLS
> connections). Perhaps this is something that can be done as part of
> security considerations, or may even be subject to its own in the draft.
> Cheers
> Pieter
>
>
> *From:* Richard Barnes 
> *Sent:* Tuesday, June 25, 2024 9:56 PM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* [OAUTH-WG] Re: Call for adoption - PIKA
>
> Hi all,
>
> Replying to the top of the thread again to recap the arguments so far.
> (Hoping the chairs will give us a moment more to discuss before calling
> cloture.)
>
> It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t.
> the X.509-based mechanisms in the current draft.  In particular, we're all
> developers of relying party software, and it seems like we're all OK with
> doing X.509 (contra Mike's point about application-level X.509).
>
> If I understand Mike and Giuseppe correctly, they want to be less
> prescriptive about how the PIKA signer establishes their authority for an
> "iss" value, so that an OP could use some other mechanism (e.g., OpenID
> Federation).  It sounds like Mike at least is OK with the draft aside from
> this point.
>
> I wo

[OAUTH-WG] Re: We cannot trust Issuers

[Tom Jones]

There are many cases of verifiers colliding with issuers.
Police recording all traffic stops looking for patters of abuse.
One time time and similar use restrictions on tokens.
Patterns of use that indicate fraud or abuse of financial or tracking by
third parties.
Password or vendor relations apps.
Any advertising.
Frequent buying programs.
I personally don't think that this topic is well considered against real
world situations.


thx ..Tom (mobile)

On Wed, Jul 31, 2024, 6:32 AM Brian Campbell  wrote:

>
>
> On Tue, Jul 23, 2024 at 11:15 AM Leif Johansson  wrote:
>
>> On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote:
>> > I would observe that any solution based on garden-variety digital
>> > signature (not something zero-knowledge like BBS / JWP) will have
>> > problems with issuer/verifier collusion.  One-time tokens and batch
>> > issuance don't help.  There is no such thing as SD-JWT with
>> > issuer/verifier collusion resistance.  At best you could have SD-JWP.
>> >
>> > I don't think this needs to be a blocker on SD-JWT.  There are use
>> > cases that don't require issuer/verifier collusion resistance.  We
>> > should be clear on the security considerations and warn people away
>> > who care about issuer/verifier collusion resistance, and accelerate
>> > work on SD-JWP if that's an important property to folks.
>> >
>>
>>
>> +1 on this
>>
>
> I'm generally a +1 on this too.  There is an attempt at a discussion
> around unlinkablity in the privacy considerations at
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability
> currently. Concrete suggestions to that text about how to better frame the
> risks and difficulties around Issuer/Verifier Unlinkability (perhaps
> especially with respect to something like a government issuer compelling
> collusion from verifiers) would be welcome for consideration.
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> 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

[OAUTH-WG] Re: SD-JWT and Unlinkability

[Tom Jones]

that doesn't answer the question about users randomly selecting some to
store and some to reject.  This seems to me like user private information.
As is most of the feedback to the issuer from the wallet.
Peace ..tom jones


On Sat, Sep 21, 2024 at 7:30 AM Daniel Fett  wrote:

> Hi Dick,
>
> Batch credential (not claims) issuing has become the default approach to
> circumvent the inherent limitations of salted-hash-based credentials
> formats. This was neither invented by us, nor is it unreasonable to ask
> implementers to do it. Protocols such as OpenID4VCI support it.
>
> -Daniel
> Am 21.09.24 um 06:42 schrieb Dick Hardt:
>
> Is it really going to be practical to batch issue claims, and have the
> holder randomly choose between them on presentation?
>
> As an implementer, what is the right number of claims to be in a batch?
>
> This section of the draft reads as a hack to add a new capability
> (unlinkability) to a mechanism that did not have that as a design objective.
>
> This is going to be like the "alg":"null" for SD-JWT. :-)
>
>
> ___
> 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

[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones]

As I tried to make clear in an earlier post - there is no such thing as a
TLS cert. Various attributes MUST be included in TLS certs and that
combination is well known and easy to request.

thx ..Tom (mobile)

On Wed, Sep 18, 2024, 12:44 PM Michael Jones 
wrote:

> Hi Richard,
>
>
>
> We clearly had different expectations for the 2nd call for adoption.
> Yes, I was in the room in Vancouver but nowhere in the minutes
> 
> does it say that the authors were not to incorporate the feedback from the 1
> st call for adoption to improve the specification before the 2nd call,
> nor do I remember that being said.  Given that useful feedback was known to
> the authors as a result of the 1st call, I was quite surprised not to see
> the draft improved before the 2nd call by incorporating it, as were
> others.  Yes, the problems were **acknowledged** in the presentation, but
> they could have been **corrected**.  Not correcting them was a missed
> opportunity.
>
>
>
> As it is, once I reviewed the draft for the 2nd call and realized the
> feedback wasn’t incorporated, it felt to me like an attempt at a do-over –
> running the 2nd call on essentially the same content as the 1st, but
> hoping for a different outcome.  Anyway, that’s my perception of the
> situation.
>
>
>
> Thank you for responding to my 6 points.  I’m not going to go
> back-and-forth on them individually at the moment, as I think the chairs
> should first figure out what to do about the new call for adoption, the
> feedback received during it, and next steps.
>
>
>
> I will say that, given the legal and compliance issues raised by Vladimir
> and DW, I personally don’t feel like we’d be on solid ground to adopt the
> spec until at least the spec clearly says that the certificates used MUST
> NOT be TLS certificates.
>
>
>
> Sincerely,
>
> -- Mike
>
>
>
> *From:* Richard Barnes 
> *Sent:* Wednesday, September 18, 2024 7:28 AM
> *To:* Michael Jones 
> *Cc:* Rifaat Shekh-Yusef ; oauth 
> *Subject:* Re: [OAUTH-WG] Re: Call for adoption - PIKA
>
>
>
> Hi Mike,
>
>
>
> We addressed these points in the presentation in YVR, where we had a
> successful IRL adoption call based on the premise that these could be
> worked in the WG post-adoption. You were in the room for that, so I'm
> surprised that these concerns are being re-raised now.  The chairs advised
> us not to revise the draft before we confirmed that adoption call on the
> list.
>
>
>
> Nonetheless, here's a quick recap of what we said in YVR:
>
>
>
> 1. Application-level use of PKI -- Several developers have opined on-list
> that this is not a practical barrier, and that the resilience benefits of
> PIKA are worth the extra effort.
>
>
>
> 2. Reuse of keys -- The core idea here is to make PIKA signing
> certificates different from certificates you would use on a web server.
> For example, we can require that the PIKA signing certificate use a prefix,
> say containing a SAN for _pika.example.com when authenticating the issuer
> URL .
>
>
>
> 3. Authorities with paths not secured -- Paths are not secured today, with
> HTTPS-based discovery.  Anyone who controls the domain on which an issuer
> is hosted can impersonate that issuer.  PIKA is not making any change in
> that regard.
>
>
>
> 4. Odd hybrid -- I'm not sure how to respond to "odd" as an engineering
> concern.  JOSE and X.509 have been intermixed since the "x5c" parameter was
> introduced.  The layering here is actually quite clean: JWK and X.509 talk
> about different keys, with the X.509 keys "blessing" the JWKs.
>
>
>
> 5. Upgrade path -- There is a trade-off here between concreteness and
> future-proofing.  Our proposal is to continue to have PIKA articulate a
> concrete, PKI-based mechanism, but also provide some notes on how one would
> update it to use different authority mechanisms.
>
>
>
> As to the direction of travel: The direction this document is trying to
> move is orthogonal to the axis you're talking about.  The OAuth ecosystem
> already relies on X.509 in the ways we are relying on it here.  We are just
> expressing that reliance in JWS instead of HTTPS.  If, in the future, the
> OAuth ecosystem relies more on JWS in the places it currently uses X.509,
> we can make a PIKAv2 that takes that up.  But that is not the world we live
> in today.
>
>
>
> Best,
>
> --Richard
>
>
>
> On Mon, Sep 16, 2024 at 6:23 PM Michael Jones 
> wrote:
>
> Hi Richard.  Thanks for the quick response.
>
>
>
> What surprises me is that a lot of substantive feedback was communicated
> during the prior call for adoption and as far as I can tell, none of the
> problems identified were corrected in the draft before the second call for
> adoption.  Incorporating it could have both solved the real problems
> identified and likely 

[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones]

This is not the way I used PKI for user proofing.  For convenience we added
the Subject Alternative Name (SAN) which I guess is what you mean by a TLS
certificate. This cert key was added to the TPM and used to sign JSON
messages from the client to the server.

Please don't mix the attributes of the PKI for the actual purpose of the
key and cert.

Peace ..tom jones


On Tue, Sep 17, 2024 at 1:01 PM Vladimir Dzhuvinov 
wrote:

> I frankly don't see how the central premise of PIKA - the reliance on a
> TLS web domain certificate - can be made to work in practice.
>
>
> Reasons: Infrastructure in the real world, mixing of concerns, conflict
> with CA policies and CAB Forum requirements, NIST etc guidance compliance
> issues.
>
>
> The argument - JWKs are already published at an HTTPS URL - so let's take
> the private key from the web reverse proxy (assuming there is no HSM) and
> start signing JWTs at some application with it - how I would be able to
> make this argument at some company X.
>
> When we look at how infrastructure is setup and administered - even if we
> here in the OAuth WG decide to say "using the private TLS key for other
> purposes is entirely okay" - there are significant practical issues with
> this. It's not just a matter of being theoretically able to cross from the
> app layer into the TLS layer. These two layers are typically managed by
> different departments in orgs, and there are good reasons to isolate them.
> I can't imagine being able to go to the admins and say, make me a copy of
> the private key so I can sign JWTs with it, or let me install this service
> on your infra to sign my JWTs.
>
> Let's also think about the potential legal and compliance issues.
>
> CAs that issue certs that prove web domain control have policies. These
> policies are linked to the EKU values in the certs. Using the cert to sign
> stuff other than that expressly identified in the CA policy and the
> extKeyUsage fields can be seen as breaking those policies.
>
> https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf
>
> 3.6 Installation and Use of Your Certificate
>
> The purpose of Your Certificate is to authenticate and encrypt Internet
> communications.
>
> I'd also suggest to go and check whether the CA / Browser Forum, in its
> "Baseline Requirements for the Issuance and
> Management of Publicly‐Trusted TLS Server Certificates" does not stipulate
> an overarching policy for CAs that generally prohibits issue of TLS certs
> with additional EKU values.
>
> Orgs that seek compliance with NIST and similar guidance are likely to see
> issue with this approach too. Documents like NIST Special Publication
> 800-57 / Recommendation for Key Management.
>
> I'm not in favour of adopting this spec as it is in the WG. Let's consider
> the practical situation apart from what seems technically possible.
>
> I made a diff between drafts 01 & 02 and noticed that in 02 the policy
> issues of using CA TLS certs for PIKA were probably recognised to some
> degree, in the "5.2. Signing Key Compromise" section.
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-barnes-oauth-pika-00&url2=draft-barnes-oauth-pika-01&difftype=--html
>
> Apart from the "5.2. Signing Key Compromise" section, draft 02 that is
> now proposed for adoption is identical to the original 01 that wasn't
> adopted in June. It's okay to explain the intent to resubmit without
> changes, just as it's okay to disagree on a particular adoption. I get it
> that the topic of PIKA feels contentious.
>
>
> Vladimir Dzhuvinov
>
> On 03/09/2024 13:47, Rifaat Shekh-Yusef wrote:
>
> All,
>
> As per the discussion in Vancouver, this is a call for adoption for the *Proof
> of Issuer Key Authority (PIKA) *draft:
> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by *Sep 17th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Tom Jones]

boy - this came in out-of-context.
I hope that wasn't caused by me posting to the wrong site.
I was responding to someone else about trusting the telco.
We can see cases where the phone number maps to something real.
Trusting the telcos to map the number to something real is basically
unacceptable to them.
Several countries (Estonia, India) try to register SIM cards and use the
SIM as a link to something real. That does make sense from a security
standpoint.
But that hasn't worked well in practice and now physical sims are not even
available in some countries (most phone in US)

So - what trust infrastructure "needs to exist". That's a real question
that deserves a real answer. Not clear who has the smarts and authority to
do that.

Peace ..tom jones


On Thu, Dec 26, 2024 at 10:08 AM Pierce Gorman 
wrote:

> What mechanism(s) are you referring to that “involves trusting the telco”?
>
>
>
> Telecoms providers vary widely in their abilities (and regulatory
> regimes), and the telecoms technology continues to evolve.
>
>
>
> Voice over IP (VoIP) wasn’t really a thing 30 years ago but I will assert
> the majority of network-to-network interconnection is now dominated by
> VoIP.  And, the dominant VoIP protocol (Session Initiation Protocol aka
> SIP) was originally designed to operate peer-to-peer, and it isn’t hard to
> imagine a day when peer-to-peer will be the dominant operation instead of
> telecoms network to telecoms network.
>
>
>
> Whatever mechanism you think would be the “good thing” needs to be able to
> exist independently of existing telecoms infrastructure.
>
>
>
> Pierce
>
>
>
> CONFIDENTIAL
>
> *From:* Tom Jones 
> *Sent:* Tuesday, December 24, 2024 12:34 PM
> *To:* Wayne Chang 
> *Cc:* pe...@acm.org; John Wunderlich ; IETF oauth WG <
> oauth@ietf.org>
> *Subject:* [OAUTH-WG] Re: Alternative text for sd-jwt privacy
> considerations.
>
>
>
> *EXTERNAL EMAIL*
>
> There is always the potential to come up with a cred that will be accepted
> as enabling access to some resource.
>
> There are some proof mechanisms that state that the bearer has a cred that
> enables access.
>
> What we have not achieved is a mechanism that ties the cred to the holder
> without an ID number binding to the holder.
>
> That would be a good thing - but the only way I know involves trusting the
> telco - which we all know is a dead end.
>
> What other mechanism can bind the holder to the device w/o the telco (or
> do we just nationalize the telcos again.)
>
>
>
> Peace ..tom jones
>
>
>
>
>
> On Tue, Dec 24, 2024 at 10:29 AM Wayne Chang  wrote:
>
> No, I don’t mean an ID number. More so attributes of an entity attested by
> a non-governmental entity, and it could use privacy enhancing cryptography
> in this steelman.
>
> Best,
>
> Wayne Chang
>
> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
> <https://www.linkedin.com/in/waynebuilds/>
>
>
>
>
>
> On Wed, Dec 25, 2024 at 02:17 Tom Jones 
> wrote:
>
> if by ID you mean ID number - then it is a tracking number.
>
> Isn't it super obvious - why are we pretending to be privacy enabling?
>
>
>
> Peace ..tom jones
>
>
>
>
>
> On Tue, Dec 24, 2024 at 10:15 AM Wayne Chang  wrote:
>
> Tom, how do you feel about private sector issued ID?
>
> Best,
>
> Wayne Chang
>
> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
> <https://www.linkedin.com/in/waynebuilds/>
>
>
>
>
>
> On Wed, Dec 25, 2024 at 02:04 Tom Jones 
> wrote:
>
> While Waton's statement is correct - it does not address the core problem
> with any credential that comes with an ID.
>
>
>
> All reusable IDs enable tracking.  Full Stop.
>
> All government issued ID enable tracking. Just like social insurance
> number or any other cred.
>
> So - if you want privacy - don't release the ID number.
>
>
>
> Peace ..tom jones
>
>
>
>
>
> On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd  wrote:
>
> I see that people are uncomfortable with making any mandates, and so I've
> tried to be purely descriptive in this proposal. I leave it to the WG to
> decide where to put it, but I see it as a wholesale replacement for some
> sections to emphasize clarity.
>
>
>
>  "SD-JWT conceals only the values that aren't revealed. It does not meet
> standard security notations for anonymous credentials. In particular
> Verifiers and Issuers can know when they have seen the same credential no
> matter what fields have been opened, even none of them. This behavior may
> not accord with what users naiv

[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Tom Jones]

This problem was clearly demonstrated by the California mDL hackathon where
the default presentation was ALL DATA. That is the easiest path, so it
remains the one most taken. We have known since standards were first
introduced that they immediately create a drive to the bottom. This will be
the fate of this standard as well. The most permissive interpretation will
be the most common. The user's desires will not be met.

thx ..Tom (mobile)

On Tue, Dec 24, 2024, 6:34 AM Watson Ladd  wrote:

> I see that people are uncomfortable with making any mandates, and so I've
> tried to be purely descriptive in this proposal. I leave it to the WG to
> decide where to put it, but I see it as a wholesale replacement for some
> sections to emphasize clarity.
>
>  "SD-JWT conceals only the values that aren't revealed. It does not meet
> standard security notations for anonymous credentials. In particular
> Verifiers and Issuers can know when they have seen the same credential no
> matter what fields have been opened, even none of them. This behavior may
> not accord with what users naively expect or are lead to expect from UX
> interactions and lead to them make choices they would not otherwise make.
> Workarounds such as issuing multiple credentials at once and using them
> only one time can help for keeping Verifiers from linking different
> showing, but cannot work for Issuers. This issue applies to all selective
> disclosure based approaches, including mdoc. "
>
> Sincerely,
> Watson
> ___
> 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

[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Tom Jones]

I am appalled!

All humans must adapt to the consent plans of this small standards group!
I for one do not plan to adapt - sorry about that!

Peace ..tom jones


On Thu, Dec 26, 2024 at 4:15 PM David Waite 
wrote:

>
>
> > On Dec 26, 2024, at 10:38 AM, Tom Jones 
> wrote:
> >
> > This problem was clearly demonstrated by the California mDL hackathon
> where the default presentation was ALL DATA. That is the easiest path, so
> it remains the one most taken. We have known since standards were first
> introduced that they immediately create a drive to the bottom. This will be
> the fate of this standard as well. The most permissive interpretation will
> be the most common. The user's desires will not be met.
> >
>
> The consequence of splitting out the policy for controlling data release
> from the issuing authority is that the complexity that was the business
> logic for handling requests, determining if they are appropriate for the
> use case, prompting the user for consent, etc. is now all complexity pushed
> into the (likely third party) user agent.
>
> Architectures like PRIVACYPASS create individual solutions to release a
> particular type of information in the most privacy-preserving manner they
> are capable of. This sort of business logic is baked into the protocol, and
> the scope of implementation is thus boxed to solve that particular problem.
> The user agent can only work per the spec if it intends to work properly,
> and following the specification (hopefully) leads to a complete
> implementation.
>
> The majority of verifiable credentials systems proposed have no such
> bounds - which is one reason you are likely to see credentials often scoped
> to be issued only to specific, qualified wallets in production. Those
> specific user agents will enforce the required security and privacy
> requirements the issuer has for their credential. That is both their own
> policy logic to be enforced (such as a credential being bound to hardware),
> as well as their own requirements for appropriate user behavior (such as
> mandatory authentication and mandatory disclosure before the credential is
> released). That could include verifier authentication and having the holder
> agent confirm the verifier is authorized by the issuer to make the sort of
> request they are making - before a user consent prompt ever enters the
> picture.
>
> You could say that the captcha usage of privacy pass and AAMVA mDL usage
> are the same in that they develop trust frameworks that define the network
> of acceptable participants. I suspect however that the requirements for the
> latter contain significantly more requirements and potentially new
> technical works.
>
> A mDL hackathon has likely not set such policy or mandated that mDL and
> readers abide by it. They may not even have wanted to limit participants to
> having support for specifying complex queries (especially with the
> OpenID4VP query language changes which occurred recently). I’m not
> surprised a hackathon defaulted to a wide-open attribute policy.
>
> -DW
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: SD-JWT linkability

[Tom Jones]

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  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

[OAUTH-WG] Re: SD-JWT linkability

[Tom Jones]

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 
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 
> *Sent:* Monday, December 16, 2024 12:50 PM
> *To:* Watson Ladd 
> *Cc:* IETF oauth WG 
> *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  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

[OAUTH-WG] Re: SD-JWT linkability

[Tom Jones]

i don't disagree with Paul - my comments addressed the text of the change.
Will "Disclosures" be a part of the standard (even security concerns?)
If that is the case, then the means to address the disclosures will need to
be realistic.

AFAIK the only proposed use of the SD-JWT is in OID4VP.  In that case the
selective disclosure will be irrelevant as the means to disclose the
selection will be inadequate.  So the SD-JWT may well technically work, but
the first use will be fraudulent as the selection will not be by informed
user consent.

Peace ..tom jones


On Tue, Dec 17, 2024 at 12:05 PM Paul Bastian 
wrote:

> I think  people on this list are overly critical towards SD-JWT and I
> don't understand it. I'm not aware that these kind of statements have
> been done in other IETF standards in a comparable context. Please
> correct me why neither JWT, CWT, JOSE, COSE, CBOR nor X.509 have
> specific text about these kind of things. RFC7049 doesn't even have a
> privacy consideration section although it contains linkable data
> structures that may be utilized to track users.
>
> SD-JWT is a data container that brings some additional features to
> JWT/JWS, but nothing more than that and we shouldn't treat it
> differently. 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.
>
> Best regards,
>
> Paul
>
> On 13.12.24 15:30, Carsten Bormann wrote:
> > This is all great, but it is informative text except for a few sprinkled
> interoperability keywords “for the implementer” (when, apparently, it
> already has been decided to use this mechanism).
> >
> > The point, however, is that this specification has a limited area of
> applicability.
> > Outsourcing security decisions about this to an unwitting user is never
> the right approach.
> > The assumption that a user will intuitively understand the consequences
> of disclosure is a tall order.
> > (“Intuitive” is code for “familiar”, and every second five people are
> born that are not familiar with the consequences.)
> >
> > Beyond the nice discussion, usage of the mechanism needs to be governed
> by a strong, fully actionable applicability statement.
> >
> > Grüße, Carsten
> >
> > ___
> > 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
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: SD-JWT linkability

[Tom Jones]

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 
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 
> *Gesendet:* Dienstag, 17. Dezember 2024 02:26
> *An:* Pierce Gorman 
> *Cc:* pe...@acm.org; IETF oauth WG 
> *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 
> *Sent:* Monday, December 16, 2024 12:50 PM
> *To:* Watson Ladd 
> *Cc:* IETF oauth WG 
> *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  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:/

[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Tom Jones]

While Waton's statement is correct - it does not address the core problem
with any credential that comes with an ID.

All reusable IDs enable tracking.  Full Stop.
All government issued ID enable tracking. Just like social insurance number
or any other cred.
So - if you want privacy - don't release the ID number.

Peace ..tom jones


On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd  wrote:

> I see that people are uncomfortable with making any mandates, and so I've
> tried to be purely descriptive in this proposal. I leave it to the WG to
> decide where to put it, but I see it as a wholesale replacement for some
> sections to emphasize clarity.
>
>  "SD-JWT conceals only the values that aren't revealed. It does not meet
> standard security notations for anonymous credentials. In particular
> Verifiers and Issuers can know when they have seen the same credential no
> matter what fields have been opened, even none of them. This behavior may
> not accord with what users naively expect or are lead to expect from UX
> interactions and lead to them make choices they would not otherwise make.
> Workarounds such as issuing multiple credentials at once and using them
> only one time can help for keeping Verifiers from linking different
> showing, but cannot work for Issuers. This issue applies to all selective
> disclosure based approaches, including mdoc. "
>
> Sincerely,
> Watson
> ___
> 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

[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Tom Jones]

if by ID you mean ID number - then it is a tracking number.
Isn't it super obvious - why are we pretending to be privacy enabling?

Peace ..tom jones


On Tue, Dec 24, 2024 at 10:15 AM Wayne Chang  wrote:

> Tom, how do you feel about private sector issued ID?
>
> Best,
> Wayne Chang
> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
> <https://www.linkedin.com/in/waynebuilds/>
>
>
> On Wed, Dec 25, 2024 at 02:04 Tom Jones 
> wrote:
>
>> While Waton's statement is correct - it does not address the core problem
>> with any credential that comes with an ID.
>>
>> All reusable IDs enable tracking.  Full Stop.
>> All government issued ID enable tracking. Just like social insurance
>> number or any other cred.
>> So - if you want privacy - don't release the ID number.
>>
>> Peace ..tom jones
>>
>>
>> On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd 
>> wrote:
>>
>>> I see that people are uncomfortable with making any mandates, and so
>>> I've tried to be purely descriptive in this proposal. I leave it to the WG
>>> to decide where to put it, but I see it as a wholesale replacement for some
>>> sections to emphasize clarity.
>>>
>>>  "SD-JWT conceals only the values that aren't revealed. It does not meet
>>> standard security notations for anonymous credentials. In particular
>>> Verifiers and Issuers can know when they have seen the same credential no
>>> matter what fields have been opened, even none of them. This behavior may
>>> not accord with what users naively expect or are lead to expect from UX
>>> interactions and lead to them make choices they would not otherwise make.
>>> Workarounds such as issuing multiple credentials at once and using them
>>> only one time can help for keeping Verifiers from linking different
>>> showing, but cannot work for Issuers. This issue applies to all selective
>>> disclosure based approaches, including mdoc. "
>>>
>>> Sincerely,
>>> Watson
>>> ___
>>> 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
>>
> ___
> 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

[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Tom Jones]

There is always the potential to come up with a cred that will be accepted
as enabling access to some resource.
There are some proof mechanisms that state that the bearer has a cred that
enables access.
What we have not achieved is a mechanism that ties the cred to the holder
without an ID number binding to the holder.
That would be a good thing - but the only way I know involves trusting the
telco - which we all know is a dead end.
What other mechanism can bind the holder to the device w/o the telco (or do
we just nationalize the telcos again.)

Peace ..tom jones


On Tue, Dec 24, 2024 at 10:29 AM Wayne Chang  wrote:

> No, I don’t mean an ID number. More so attributes of an entity attested by
> a non-governmental entity, and it could use privacy enhancing cryptography
> in this steelman.
>
> Best,
> Wayne Chang
> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
> <https://www.linkedin.com/in/waynebuilds/>
>
>
> On Wed, Dec 25, 2024 at 02:17 Tom Jones 
> wrote:
>
>> if by ID you mean ID number - then it is a tracking number.
>> Isn't it super obvious - why are we pretending to be privacy enabling?
>>
>> Peace ..tom jones
>>
>>
>> On Tue, Dec 24, 2024 at 10:15 AM Wayne Chang  wrote:
>>
>>> Tom, how do you feel about private sector issued ID?
>>>
>>> Best,
>>> Wayne Chang
>>> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
>>> <https://www.linkedin.com/in/waynebuilds/>
>>>
>>>
>>> On Wed, Dec 25, 2024 at 02:04 Tom Jones 
>>> wrote:
>>>
>>>> While Waton's statement is correct - it does not address the core
>>>> problem with any credential that comes with an ID.
>>>>
>>>> All reusable IDs enable tracking.  Full Stop.
>>>> All government issued ID enable tracking. Just like social insurance
>>>> number or any other cred.
>>>> So - if you want privacy - don't release the ID number.
>>>>
>>>> Peace ..tom jones
>>>>
>>>>
>>>> On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd 
>>>> wrote:
>>>>
>>>>> I see that people are uncomfortable with making any mandates, and so
>>>>> I've tried to be purely descriptive in this proposal. I leave it to the WG
>>>>> to decide where to put it, but I see it as a wholesale replacement for 
>>>>> some
>>>>> sections to emphasize clarity.
>>>>>
>>>>>  "SD-JWT conceals only the values that aren't revealed. It does not
>>>>> meet standard security notations for anonymous credentials. In particular
>>>>> Verifiers and Issuers can know when they have seen the same credential no
>>>>> matter what fields have been opened, even none of them. This behavior may
>>>>> not accord with what users naively expect or are lead to expect from UX
>>>>> interactions and lead to them make choices they would not otherwise make.
>>>>> Workarounds such as issuing multiple credentials at once and using them
>>>>> only one time can help for keeping Verifiers from linking different
>>>>> showing, but cannot work for Issuers. This issue applies to all selective
>>>>> disclosure based approaches, including mdoc. "
>>>>>
>>>>> Sincerely,
>>>>> Watson
>>>>> ___
>>>>> 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
>>>>
>>> ___
>>> 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
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org