[OAUTH-WG] Re: OAuth 2.0 Protected Resource Metadata - Implementations

[Giuseppe De Marco]

Hi

This Is not the first time I support this draft and say that, two years
ago, I was looking for an RS metadata scheme for the spid attribuite
authorities specification

I found Mike's I-D and considered the deadline I had, together with other
collegues of other national agencies, we decided to use It.

More than two years are passed from that time. The oauth protected resource
metadata was also distributed in the federation trust chains

It works, It clearly defines how an RS should present its metadata for
interoperability, I believe that It represents an important resource for
architects and developers, I support It as I consider It a consolidated
approach from my experience

Il mer 10 lug 2024, 19:43 Michael Jones  ha
scritto:

> OpenID Federation implementations use the Protected Resource Metadata
> definitions in this specification.  Among others, Connect2ID and Authlete
> have OpenID Federation implementations.  I know that it’s deployed in the
> Italian SPID CIE national federation.
>
>
>
> -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Wednesday, July 10, 2024 7:35 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] OAuth 2.0 Protected Resource Metadata -
> Implementations
>
>
>
> All,
>
> As part of the shepherd write-up for the OAuth 2.0 Protected Resource
> Metadata document, we are looking for information about implementations of
> this draft.
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-06.html
>
>
> Please, reply on the mailing list with any implementations that you are
> aware of to support this document.
>
> Regards,
> Rifaat
>
>
> ___
> 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: Product Support for RFC8414 well-known URIs

[Giuseppe De Marco]

You made a very good point, see

https://openid.net/specs/openid-federation-1_0.html#name-obtaining-federation-entity

Il mer 3 lug 2024, 19:03 Rafael Freitas  ha
scritto:

> But does the OpenID implementation really go against RFC 5785? I'm
> re-reading it and I don't think it does, I'll elaborate, citing said RFC:
>
> > 1. When this happens, it is common to designate a "well-known location"
> for such data, so that it can be easily located.  However, this approach
> has the drawback of risking collisions, both with other such designated
> "well-known locations" and with pre-existing resources.(...)
> Here they clearly communicate a concern with avoiding collisions.
>
> > (...)To address this, this memo defines a path prefix in HTTP(S) URIs
> for these "well-known locations", "/.well-known/".  Future specifications
> that need to define a resource for such site-wide metadata can register
> their use to avoid collisions and minimise impingement upon sites' URI
> space.(...)
> Here they talk about site-wide metadata, which is not necessarily
> domain-wide metadata. Nowadays it is fairly common for a site to have a
> path prefix instead of a sub-domain.
>
> > 3. (...) A well-known URI is a URI [RFC3986] whose path component begins
> with the characters "/.well-known/" (...)
> So, for example, for a well known URI of "oauth-authorization-server", the
> well-known URI would be "/.well-known/oauth-authorization-server". This
> does not specify that the path can not have any other components before
> this, it only says that any well known URLs must be prefixed with
> "/.well-known/".
>
> > (...)For example, if an application registers the name 'example', the
> corresponding well-known URI on 'http://www.example.com/' would be '
> http://www.example.com/.well-known/example'. (...)
> I think this was a bad explanation because the word "example" appears in
> two places, generating some ambiguity. But note that they do not talk about
> a domain, but about an application. So I think it would follow that if the
> application registered the name (they don't talk about domains, but instead
> about names) 'http://www.myhoster.com/example' the corresponding
> well-known URI would be ''http://www.myhoster.com/example/.well-known/;.
>
> > (...) Note that this specification defines neither how to determine the
> authority to use for a particular context, nor the scope of the metadata
> discovered by dereferencing the well-known URI; both should be defined by
> the application itself.(...)
> To me this part nails the point home. They never intented to specify how
> URIs are dereferenced. If they meant for well known URIs to always be at
> the root of the domain, you would have already determined the authority for
> a given domain, and the scope for the metadata. But they leave it to each
> application.
>
> So I think it is possible to respect both RFC 5785 and the OpenID
> Specification. And regardless, requiring well-known not to be a sub-path of
> a domain is rather impractical, to the point where I think it's more likely
> for this RFC to not be adopted than for every OAuth server to obtain it's
> own domain / subdomain registry.
>
> ___
> 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

[Giuseppe De Marco]

Hey Richard,

Openid Discovery apparently doesn't get popular in the gov field, or at
least not alone and without some sort of trusted registries.
Openid Connect didn't get wide adoption in the R field that is still
using SAML2 with x.509 certificates mixed with a secured metadata exchange
mechanism mediate by trusted third parties, where the X.509 certificates
are distributed within the metadata and without any revocation mechanism
based on CRL/OCSP.

The previous two examples represent two important real-world large scale
deployment domains.

PIKA is a trust framework aiming to support the main trust model categories
we may have in mind, that we can categorize as follows:

Direct Trust: Trust is established directly between two parties without
intermediaries (bilateral relationship).
Third-Party Trust: Trust is facilitated by a trusted third party (Trust
Anchor, mechanisms of transitive trusts included).
Web of Trust: Each participant makes individual decisions about whom to
trust (end to end or multiple Trust Anchors)

DNS+TLS attests entities identity and cryptographic material for
confidentiality of the transport, using encryption; and proof of
ownership/authority for non repudiation, using signatures.

This is a basic requirement that we need. We need it also with any other
trust framework, be this based on DID resolution web methods or openid
federation or anything else RESTful or SOAP, if web endpoint based.

The next level is represented by all the requirements related to the
mitigation about the following issues:

- spoofing attacks based on slightly modified FQDNs, the end user trusts
the FQDN and no other additional checks would block the attack
- spoofing attacks using open url injected during the transaction (the
example shared in my previous email)
- lack of control about entities behaviour (LoA of the issued data,
accountability, rp overasking, categories of audiences, categories of
services offered ...)
  - early prevention of protocol/cryptography misues (disable a weka
algorith automatically in a multilateral federation)
- proof of realiability about specific compliances (security, regulations,
frameworks, other industrial ...)

metadata are crucial for this, since these forces the entity configurations
and provide mitigations to the issues. The trust framework should offer at
least a way to achieve this, because it should aim to be a framework
allowing the impl to use its tools to solve the common problems.

we may have different metadata for different scopes: administrative,
protocol specific.
we should have multiple cryptographic keys for different scopes: trust,
application protocols such as particular roles or features (key for AS, RP,
RS)

I am interested expanding the scopes of PIKA to offer in its framework one
or more solutions to the issues listed above if PIKA aims to provide
solutions to common problems.
In PIKA I read that its sole scope is "define a format for Proofs of Issuer
Key Authority", if confirmed no pain, it's legitimate (apologies for having
forced you in useless conversations).

According to the current PIKA draft, here my revision points:

- OpenID Federation (remove Connect)
- the revocation reasons in draft 35 was changed and simplified, please
update them accordingly or specify that for the scopes of PIKA other are
defined (in particular if expired to RFC 5280, as they was in openid
federation before the latest changes)
- the openid federation historical keys endpoint response contains only
public keys not valid anymore

good work, never stop


Il gio 27 giu 2024, 17:07 Richard Barnes  ha scritto:

> Hi Giuseppe,
>
> Asking whether a technology addresses real-world challenges is a fair
> question.  The point of the current draft is that we have empirical
> evidence that X.509-based authentication works well for many cases, given
> the very wide usage of things like OpenID Connect Discovery.  PIKA seeks to
> address some operational deficiencies in those models, without changing the
> trust model.
>
> --Richard
>
> On Wed, Jun 26, 2024 at 8:21 PM Giuseppe De Marco 
> wrote:
>
>> Hi Ethan,
>>
>> I have experience implementing LDAP clients with SASL and SSL, SAML2 SP,
>> IDP, MDQ, as well as OpenID Connect RP, OP, and RS. It's clear that X.509
>> is foundational to our digital infrastructure, making implementation
>> straightforward due to the widespread availability of supporting libraries.
>>
>> However, X.509 has not addressed all issues; it would be unwise to ignore
>> its limitations and pretend it fits all needs perfectly.
>>
>> I can be an advocate for PIKA and am eager to delve deeper into the
>> technical trust requirements envisioned by the PIKA working group
>> participants. A new specification should aim to tackle the unresolved
>> issues.
>>
>> Consider this real-world example to illustrate a poi

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

[Giuseppe De Marco]

Hi Ethan,

I have experience implementing LDAP clients with SASL and SSL, SAML2 SP,
IDP, MDQ, as well as OpenID Connect RP, OP, and RS. It's clear that X.509
is foundational to our digital infrastructure, making implementation
straightforward due to the widespread availability of supporting libraries.

However, X.509 has not addressed all issues; it would be unwise to ignore
its limitations and pretend it fits all needs perfectly.

I can be an advocate for PIKA and am eager to delve deeper into the
technical trust requirements envisioned by the PIKA working group
participants. A new specification should aim to tackle the unresolved
issues.

Consider this real-world example to illustrate a point: Space Attack
Spoofing eIDs [1]. The article highlights a vulnerability due to the lack
of mechanisms for validating endpoints, which opens the door to
Man-in-the-Middle (MITM) attacks through spoofing.

>From my perspective, part of the solution lies in the trust framework
employed. Even with a vulnerability at one point, having trusted endpoints
could prevent the attack's success. If endpoints were cryptographically
attested through verifiable metadata certified by a trusted third party, or
through a trusted distribution method or trusted policy processing, the
attack would likely fail. The attacker would not be able to redirect data
to fraudulent endpoints.

Regardless of the technology, data format, or other elements used, these
may not align with our personal preferences or comfort levels, I am
interested in discussing the level of technical trust evaluation we aim to
incorporate into PIKA. Specifically, which problems are we aiming to solve,
and which are we deliberately excluding from the scope of this new
specification.

When selecting a technology for implementation, it is essential to assess
whether it addresses real-world challenges effectively. I am here to
investigate if PIKA meets these criteria currently or in the foreseeable
future, and to understand the roadmap for its development, if available.
This evaluation is vital for trusting a specification.

I was too verbose, I am sorry.
Giuseppe

[1]
https://ctrlalt.medium.com/space-attack-spoofing-eids-password-authenticated-connection-establishment-11561e5657b1

Il giorno mer 26 giu 2024 alle ore 19:08 Ethan Heilman 
ha scritto:

> I strongly support this draft and would have immediate uses for PIKA
> if standardized.
>
> As someone who builds OIDC relying party software I am not worried
> about the X.509 certificate requirement, nor do I consider dependence
> on X.509s or the Web PKI to be an onerous requirement. I already have
> to deal with parsing and creating X.509 certificates in my relying
> party software.
>
> Given that JWK Set URI's use the Web PKI to authenticate the JWKs they
> serve via HTTPS, it only seems natural we would use that very same
> system, the Web PKI, to authenticate JWKs directly.
>
> Thanks,
> Ethan
>
>
> On Tue, Jun 25, 2024 at 8:46 PM Kristina Yasuda
>  wrote:
> >
> > Sorry to chime in late as well…
> > I support adoption of this draft. I have read the thread and to me it
> seems like there is a mechanism being proposed that solved a concrete
> problem in a simple manner. Some of the discussion can happen after the
> draft is adopted.
> > Best,
> > Kristina
> >
> >
> > On Wed, Jun 26, 2024 at 7:49 AM Joseph Salowey  wrote:
> >>
> >> Sorry to chime in late here. I'm in favor of adopting this draft.
> While I realize that X.509 isn't for everyone, there is an established
> community of users out there that overlaps with OAUTH users.  I think there
> are needs to both separate the distribution of the keys from the
> establishment of trust in those keys and in the auditability of the process
> of distribution.  I think this draft establishes a deployable mechanism
> based on existing technology.  X.509 is a good starting point and
> additional mechanisms can be added as needed.
> >>
> >> Cheers,
> >>
> >> Joe
> >>
> >> On Tue, Jun 25, 2024 at 3:12 PM Watson Ladd 
> wrote:
> >>>
> >>> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
> >>>  wrote:
> >>> >
> >>> > The other critique I voiced of the approach is that the
> application-level X.509 certificate can be used to secure the HOST part of
> the issuer, but not the entire issuer, since in general, the issuer will
> contain a PATH.  Yes, the service hosting the issuers controls all the
> paths, as Richard replied earlier, but it’s not the service who is the
> attacker that this enables.  The attackers that not securing the PATH
> enables are the tenants themselves.
> >>> >
> >>> >
> >>> >
> >>> > An attacker could host a tenant at the service and get an X.509
> certificate securing the HOST part of its issuer.  However, because a
> legitimate tenant at another path shares the same HOST, the attacker can
> copy its X.509 certificate chain and utilize a substitution attack to make
> unauthorized statements about the victim tenant – statements that were not
> made by the hosting 

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

[Giuseppe De Marco]

> If we have a tenant" distinguished by a path, there is already a security
issue with giving it the X509 certificate. It could then imitate any
other tenant
on that server already. That's why we use reverse proxies and put the
certificate only on the proxying machines.

In large deployments, like an entire national public service domain or
multinational organization, using the model you propose may represent a
security issue because, behind the proxy, the services/endpoint are
supposed to be not secured at the application level

Threats like rogue emploies or adversaries taking control of the proxy,
might take control of all the endpoints behaviour, while the additional
application security layer would keep this out of the control of who
controls the proxy

When we mention a trust that scales I also think about these distinct
layers enforcing the security of each single endpoint




Il mer 26 giu 2024, 00:12 Watson Ladd  ha scritto:

> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
>  wrote:
> >
> > The other critique I voiced of the approach is that the
> application-level X.509 certificate can be used to secure the HOST part of
> the issuer, but not the entire issuer, since in general, the issuer will
> contain a PATH.  Yes, the service hosting the issuers controls all the
> paths, as Richard replied earlier, but it’s not the service who is the
> attacker that this enables.  The attackers that not securing the PATH
> enables are the tenants themselves.
> >
> >
> >
> > An attacker could host a tenant at the service and get an X.509
> certificate securing the HOST part of its issuer.  However, because a
> legitimate tenant at another path shares the same HOST, the attacker can
> copy its X.509 certificate chain and utilize a substitution attack to make
> unauthorized statements about the victim tenant – statements that were not
> made by the hosting service.
> >
> >
> >
> > This attack was not addressed, and I believe is intrinsic to the
> decision not to protect the entire issuer value.
> >
> >
> >
> > I believe that adopting this draft would result in this attack occurring
> in practice.
>
> To be clear, drafts get modified by the WG after adoption so adoption
> is not the same thing as WGLC.
>
> However, I'm not sure I understand your attack scenario. If we have a
> "tenant" distinguished by a path, there is already a security issue
> with giving it the X509 certificate. It could then imitate any other
> tenant on that server already. That's why we use reverse proxies and
> put the certificate only on the proxying machines.
>
> Sincerely,
> Watson
>
>
>
> --
> 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

[Giuseppe De Marco]

Technology alone cannot solve this problem unless a mapping of different
trust frameworks and rules to handle all behaviors/cases is defined and
voluntarily adopted. The parties must be aware that they are dealing with
an entity operating under a different trust framework, and they must
evaluate whether they recognize and support that framework, and determine
which rules to apply.

There are projects actively working in this field to develop an
interoperability profile between multiple frameworks, such as SIDI HUB.

Il giorno gio 13 giu 2024 alle ore 03:13 Tom Jones <
thomasclinganjo...@gmail.com> ha scritto:

> But the core problem is all of the trust frameworks, like federation, roll
> their own conditions and freshness/revocation mechanisms. In other words if
> the same attributes from one trust framework were passed to an alternative
> framework, it is likely to fail.  There is no interop even under
> consideration.
>
> ..tom
>
> thx ..Tom (mobile)
>
> On Wed, Jun 12, 2024, 5:39 AM Giuseppe De Marco 
> wrote:
>
>> Hi Rohan,
>>
>> I'ìm very bad in giving answers, I have to live with this, please accept
>> my excuse (it is almost certainly an attention disorder, autism or
>> something).
>>
>> Therefore here I try the Take 2.
>>
>> > Today relying parties verify the issue domain indirectly by opening a
>> TLS connection to the https URL of the issuer, which involves an X.509
>> validation of the issuer domain name in the URL.
>>
>> Amen. this give us the certaininty that the subject is exactly the one
>> we're supposing to interact with, untill the DNS were not compromised and
>> an evil endpoint with let's encrypt would appear on the way. Therefore the
>> decision about  the trust anchor to trust is crucial.
>> At the same time I use to trust (and love) let'sencrypt, therefore
>> addings additional layers helps me in supporting all the CAs attested in
>> the CAB forum and at the same time add additional security, policy and
>> interoperability chjecks using another layer.
>>
>> > What is the problem with the relying party taking a certificate and
>> validating the issue domain name directly using the same certificate?
>>
>> it is not a problem but a requirement. The relying party MUST do this.
>> After doing this and got the assurance asbout the domain name, a more
>> advanced trust establishment may occur where requirements need this.
>> I have this requirements.
>>
>> A Friend sent to me a picture of a mushroom he has picked. An popular
>> cloud provider, using AI, attested it as very good for cooking.
>> He didn't trust that "trust anchor" even if so popular and fancy,
>> therefore he has double checked with me.
>> According to my experience that mushroom was an amanita muscaria. It's
>> still a mushroom, but you cannot attest the compliance of it to your needs
>> if you don't add additional checks.
>>
>> additional layers for additional frameoworks and compliance checks
>> satisfy the requirements of having additional checks for additional
>> property, not covered with the minimal set of requirement, like be a
>> mushroom or a FQDN using TLS.
>>
>> Another example
>>
>>
>> Il giorno mer 12 giu 2024 alle ore 14:09 Rohan Mahy 
>> ha scritto:
>>
>>> Hi,
>>> This is all interesting in terms of a larger view of big picture goals
>>> of authentication, but you didn't answer my question. Today relying parties
>>> verify the issue domain indirectly by opening a TLS connection to the https
>>> URL of the issuer, which involves an X.509 validation of the issuer domain
>>> name in the URL. What is the problem with the relying party taking a
>>> certificate and validating the issue domain name directly using the same
>>> certificate?
>>>
>>> Thanks,
>>> -rohan
>>>
>>> On Wed, Jun 12, 2024 at 7:59 AM Giuseppe De Marco 
>>> wrote:
>>>
>>>> This depends on the evaluation criteria of the verification you conduct
>>>> with a subject.
>>>>
>>>> We can agree that the initial verifiable evidence that a Trust
>>>> Anchor/CA has issued a certificate for a subject is the first indication
>>>> that the subject belongs to a 
>>>> network/framework/shared-regulation/perimeter.
>>>>
>>>> Let's consider this mailing list as a trust anchor.
>>>>
>>>> We're having a productive conversation under a common trust anchor,
>>>> where the evidence that connects us is our membership in this community,
>>>&g

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

[Giuseppe De Marco]

I support people who only want to do offline validation of the issuer
domains.
I support extensions as well, to not force people to believe that subject's
identity and cryptographic material attestation alone are sufficient (at
list in the cases where they should not according to the trust framework in
use).

I want to work with you to define, within PIKA, the best approach to enable
additional mechanisms to extend the current pika trust evaluation to more
detailed checks and inspections and in a total modular way, where openid
federation can be one of these extensions.
I support the trust evaluation mechanism starting from what already
proposed in the PIKA draft.

I want to avoid that X.509 certificate may add custom extensions to satisfy
the used trust frameworks, and therefore get bloated with informations that
go out from the original scopes of the X.509 certificates. I say this
according to the experience I had in a national SAML2 federation where
X.509 certificates was inflated in this way (sorry for giving documents in
italian, these was never been traslated):

https://www.agid.gov.it/sites/default/files/repository_files/spid-avviso-n29v3-specifiche_sp_pubblici_e_privati.pdf

The bulge of X.509 certificates represent only one of the reasons why in
Italy we have implemented openid federation.
I'm concretely interested in following the evolution of PIKA and give any
contribution you may allow me to share and do.

Il giorno gio 13 giu 2024 alle ore 09:36 Rohan Mahy 
ha scritto:

> Comment inline.
>
> On Wed, Jun 12, 2024 at 8:39 AM Giuseppe De Marco 
> wrote:
> [snip]
>
>> > Today relying parties verify the issue domain indirectly by opening a
>> TLS connection to the https URL of the issuer, which involves an X.509
>> validation of the issuer domain name in the URL.
>>
>> Amen. this give us the certaininty that the subject is exactly the one
>> we're supposing to interact with, untill the DNS were not compromised and
>> an evil endpoint with let's encrypt would appear on the way. Therefore the
>> decision about  the trust anchor to trust is crucial.
>> At the same time I use to trust (and love) let'sencrypt, therefore
>> addings additional layers helps me in supporting all the CAs attested in
>> the CAB forum and at the same time add additional security, policy and
>> interoperability chjecks using another layer.
>>
>> > What is the problem with the relying party taking a certificate and
>> validating the issue domain name directly using the same certificate?
>>
>> it is not a problem but a requirement. The relying party MUST do this.
>> After doing this and got the assurance asbout the domain name, a more
>> advanced trust establishment may occur where requirements need this.
>> I have this requirements.
>>
> [snip]
>
> I don't see why the existence of these other requirements should prevent
> people who only want to do offline validation of the issuer domain should
> be prevented from doing so. That's what PIKA is for. Likewise PIKA does not
> prevent a relying party from implementing whatever other additional
> mechanisms of arbitrary complexity the community wants to standardize.
> Thanks,
> -rohan
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - Revocation Drafts @ Tue Jun 11, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Giuseppe De Marco]

Thank you Rifaat and Arndt

and also Paul, Cristian, Kristina and Oliver for their valuable questions
(many of those embedding the answer in the smart way they use to do).

In particular for the github issues and the actions that me and other
author will be able to achieve, like:

- optioanlly protect the endpoint also with DPoP using a key specialized
for this purpose:
https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/32#issuecomment-2161206939
- further points about status list in comparison with status assertions are
collected here:
https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/50#issuecomment-2129474975
- regarding short-lived credentials and refresh token: there might be
concerns about the preservation of the LoA high, here some insights about
the refresh tokens: https://github.com/italia/eudi-wallet-it-docs/issues/178
- regarding Kris concerns I can say that the wallet doesn't obains the
revocations on behalf of the verifier: the wallet obtains the proofs that
its credentials are not revoked first of all. The wallet therefore can use
these proofs to the relying party in fully compliance to the wallet
paradigm where everything passes through the wallet. The strong privacy
requirement that demonstrate weakness with the status list is that using
status list the RP can monitor the status of a credential over time and
outside the user control, while with status assertion this cannot happen

thank you for your patience in reading all the stuffs and your interest in
this I-D,
best
G
  -

Il giorno mer 12 giu 2024 alle ore 20:52 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> Attached are the slide decks presented during this meeting.
>
> The following is a link to the meeting notes (thanks to Arndt!):
>
> https://datatracker.ietf.org/meeting/interim-2024-oauth-06/materials/minutes-interim-2024-oauth-06-202406111600-00
>
> The following is a link to the meeting video recording:
> https://www.youtube.com/watch?v=Bq6hBh8Tyg4
>
> Regards,
>  Rifaat
>
>
>
> On Mon, Apr 29, 2024 at 11:37 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> OAuth WG Virtual Interim - Revocation Drafts
>> The Web Authorization Protocol (oauth) WG will hold a virtual interim
>> meetingon 2024-06-11 from 12:00 to 13:00 America/Toronto (16:00 to 17:00
>> UTC).Agenda:Token Status Listhttps://datatracker.ietf.org
>>
>> The Web Authorization Protocol (oauth) WG will hold a virtual interim
>> meeting
>> on 2024-06-11 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).
>>
>> Agenda:
>> Token Status List
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
>> 
>>
>> OAuth Status Attestation
>> https://datatracker.ietf.org/doc/draft-demarco-oauth-status-attestations/
>> 
>>
>> Global Token Revocation
>> https://datatracker.ietf.org/doc/draft-parecki-oauth-global-
>> token-revocation/
>> 
>>
>>
>> Information about remote participation:
>> https://meetings.conf.meetecho.com/interim/?group=79913841-
>> 6dcc-4d63-a1f4-26484e75fee9
>> 
>>
>>
>>
>> --
>> A calendar subscription for all oauth meetings is available at
>> https://datatracker.ietf.org/meeting/upcoming.ics?show=oauth
>> 
>> WhenTuesday Jun 11, 2024 ⋅ 12pm – 1pm (Eastern Time - Toronto)
>> Guests
>> Rifaat Shekh-Yusef  - organizer
>> oauth@ietf.org
>> View all guest info
>> 
>> Reply for oauth@ietf.org
>> Yes
>> 
>> No
>> 
>> Maybe
>> 

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

[Giuseppe De Marco]

Hi Rohan,

I'ìm very bad in giving answers, I have to live with this, please accept my
excuse (it is almost certainly an attention disorder, autism or something).

Therefore here I try the Take 2.

> Today relying parties verify the issue domain indirectly by opening a TLS
connection to the https URL of the issuer, which involves an X.509
validation of the issuer domain name in the URL.

Amen. this give us the certaininty that the subject is exactly the one
we're supposing to interact with, untill the DNS were not compromised and
an evil endpoint with let's encrypt would appear on the way. Therefore the
decision about  the trust anchor to trust is crucial.
At the same time I use to trust (and love) let'sencrypt, therefore addings
additional layers helps me in supporting all the CAs attested in the CAB
forum and at the same time add additional security, policy and
interoperability chjecks using another layer.

> What is the problem with the relying party taking a certificate and
validating the issue domain name directly using the same certificate?

it is not a problem but a requirement. The relying party MUST do this.
After doing this and got the assurance asbout the domain name, a more
advanced trust establishment may occur where requirements need this.
I have this requirements.

A Friend sent to me a picture of a mushroom he has picked. An popular cloud
provider, using AI, attested it as very good for cooking.
He didn't trust that "trust anchor" even if so popular and fancy, therefore
he has double checked with me.
According to my experience that mushroom was an amanita muscaria. It's
still a mushroom, but you cannot attest the compliance of it to your needs
if you don't add additional checks.

additional layers for additional frameoworks and compliance checks satisfy
the requirements of having additional checks for additional property, not
covered with the minimal set of requirement, like be a mushroom or a FQDN
using TLS.

Another example


Il giorno mer 12 giu 2024 alle ore 14:09 Rohan Mahy 
ha scritto:

> Hi,
> This is all interesting in terms of a larger view of big picture goals of
> authentication, but you didn't answer my question. Today relying parties
> verify the issue domain indirectly by opening a TLS connection to the https
> URL of the issuer, which involves an X.509 validation of the issuer domain
> name in the URL. What is the problem with the relying party taking a
> certificate and validating the issue domain name directly using the same
> certificate?
>
> Thanks,
> -rohan
>
> On Wed, Jun 12, 2024 at 7:59 AM Giuseppe De Marco 
> wrote:
>
>> This depends on the evaluation criteria of the verification you conduct
>> with a subject.
>>
>> We can agree that the initial verifiable evidence that a Trust Anchor/CA
>> has issued a certificate for a subject is the first indication that the
>> subject belongs to a network/framework/shared-regulation/perimeter.
>>
>> Let's consider this mailing list as a trust anchor.
>>
>> We're having a productive conversation under a common trust anchor, where
>> the evidence that connects us is our membership in this community, under
>> the IETF Trust Anchor.
>>
>> However, this alone is not sufficient, because you must read everything I
>> say and empirically evaluate if you can trust me qualitatively.
>>
>> OpenID Federation allows the exchange of metadata to securely establish
>> interoperability and also applies policies that dynamically change this
>> metadata, adding qualitative evidence with trust marks.
>>
>> This is the advancement I found that the X.509 based PKI was not designed
>> for. I use X.509 based PKI for other purposes, since in this universe
>> everything has its right place, and I appreciate this.
>>
>> I also appreciate PIKA in a way to make this grow and get integrated with
>> other models that should not be kept out of the scope of the specification
>> if you agree and if we may have the opportunity to work together in this
>> field
>>
>> Il giorno mer 12 giu 2024 alle ore 12:47 Rohan Mahy 
>> 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 certif

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

[Giuseppe De Marco]

Hey D

Il giorno mer 12 giu 2024 alle ore 13:54 Denis  ha
scritto:

> Hi Giuseppe,
>
> Thank you for your response that was sent rather early today.  :-)
>
> This draft might be paving the way for *a* solution that might be adopted
> for the EUIDW
> ... or even paving the way for *THE* solution that will be adopted for the
> EUIDW.
>

I bring solutions after having evaluated the requirements, I found an
important privacy concern that forced me to push the nth proposal.
I strongly believe that revocations must be classified by different use
cases and that there might be different revocation mechanisms for different
use cases.
EUDIW represents only a part of what will be at the end the wallet paradigm.


> The solution proposed in the draft is purely technically based and cannot
> be considered
> to be the most effective way to address the *concerns of the end-users*.
>

let's see what happen, an idea may helps the born of other ideas.
I don't consider myself neither the most effective solution architect over
here, therefore you can imagine how modest could be my contribution.
Keep things moving will help things moving, like this conversation. Time
will show us the achievements.


> As this topic might be progressed within the SPICE WG (if it is formed),
> it could be considered
> as a narrowed field of vision with short-term benefits without considering
> the whole picture.
>

yes, the wallet paradigm could take a decade to be properly consolidated in
the digital identity field. It seems that at least 5 years was already
spent.


> You have not commented the section 6) that proposes a different approach
> taking into consideration the whole ecosystem that, anyway,
> will be necessary to consider to support TAs providers, secure OS
> providers, Rich OS providers and TEE providers.
>
> The security of a chain is composed of the security of each of the
> elements of a chain. Without a TA (and the other components
> that need to be present to support it), many kind of security problems
> cannot be correctly solved.
>

I agree with you, however these copmponents sounds outs from the status
assertions since they must be defined in the trust model and trust
framework and specifications dedicated to the trust establishemnt, like ...
Ok, you know.


>
> I have indicated why the mechanism I propose has several major advantages *for
> the end-users, *over the use of Digital Credential Status Attestations.
> In particular, it allows to *suspend* at once all the credentials
> contained in a wallet instead of *revoking* them one-by-one.
>
>
watch this:
https://github.com/peppelinux/draft-demarco-oauth-status-assertions/pull/61


>
> Now, let us switch to a vocabulary problem. The definition of a holder in
> the W3C Verifiable Credentials Data Model is the following:
>
> *holder*
> A role an entity might perform by possessing one or more verifiable
> credentials and generating verifiable presentations from them.
> Example holders include students, employees, and customers.
>
> While the definition is roughly correct, the examples are incorrect. The
> first key word is "role" while the second key word is "generating".
> It is impossible for a human being to *generate* a verifiable presentation
> because the processing power and the memory size of a human brain
> is insufficient. Hence a holder cannot be a student, an employee or a
> customer.
>
> In the same way, taking the OpenID definition which is:
>
> *Holder*
> An entity that receives Verifiable Credentials and has control over them
> to present them to the Verifiers as Verifiable Presentations.
>
> it is impossible for a human being to *present* a verifiable presentation
> because the processing power and the memory size of a human brain is
> insufficient.
>
> A solution to this problem would be to use two different terms: Holder
> Application and Holder.
>
> *Holder application*
> A role an application might support when controlling the use of one or
> more Digital Credentials and generating Digital Presentations from them.
>
> *Holder*
> An entity that has the control of a Holder Application. Examples include
> citizens, students, employees or customers.
>
> Note: I am reusing the terms from the SPICE charter, i.e., "Digital
> Credentials" and "Digital Presentations", instead of the terms used by W3C
>  "Verifiable Credentials" and "Verifiable Presentations".
>

This is an issue on openid4vci, since I desidered to align to the openid
specs even if ... the hilaurous conversation with Daniel in Rome I
mentioned.


>
> Denis
>

see you
G
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Giuseppe De Marco]

Thank you LanLan Pan,

Orie is the (co-)author of both the specifications, therefore I would
invite him to say something in this field.
I heard about the Bloom filters and I can say that they should not be
excluded from the analysis and comparisons (here Giada may say somethign
more ...).

At this stage, due to the strict deadlines, I was unfortunately forced to
use stable and well established mechanisms to satisfy the requirements,
something that from my perspective seems quite good standing in the status
assertions. Feedbacks are more than welcome, are needed!

Il giorno mer 12 giu 2024 alle ore 11:45 Lanlan Pan  ha
scritto:

> Hi Giuseppe,
>
> 2.4.5.
>> <https://www.ietf.org/archive/id/draft-steele-spice-oblivious-credential-state-00.html#section-2.4.5>Bloom
>> Filters
>> <https://www.ietf.org/archive/id/draft-steele-spice-oblivious-credential-state-00.html#name-bloom-filters>
>>
>> Appendix B.2.7 <https://rfc-editor.org/rfc/rfc8932#appendix-B.2.7> of [
>> RFC8932
>> <https://www.ietf.org/archive/id/draft-steele-spice-oblivious-credential-state-00.html#RFC8932>
>> ] mentions an application of bloom filters, that can be applied to
>> communicating credential state assuming the probabilistic nature of bloom
>> filters is acceptable to the verifier.
>>
>
> The verifier could verify credential signature  to assure that the
> credential content is correct.
> Sometimes the verifier may verify the status assertion/attestation
> signature to assure that the credential is available recently.
>
> Personally I think, bloom filter may cause false positive, which will
> result the verifier in wrong decision. Verifier should avoid to use bloom
> filter in the use case of credential verification.
>
>
> Lanlan Pan
> Giuseppe De Marco  于2024年6月11日周二 05:59写道：
>
>> Hello Everybody,
>>
>> OAuth Status Assertions replaces OAuth Status Attestations and it is
>> published here:
>> https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/
>>
>> Therefore here its html preview:
>> https://www.ietf.org/archive/id/draft-demarco-oauth-status-assertions-00.html
>>
>> Compared to the previous draft, the change in the draft name reflects the
>> feedback received on the mailing list, for which I am very grateful.
>> The work continues and tomorrow there will be an engaging discussion
>> about the new drafts concerning revocations, including status assertions,
>> status lists, and OAuth global token revocation, during the OAuth interim
>> meeting.
>>
>> From my understanding, there are several use cases for revocations, each
>> of which is addressed, either wholly or partially, in these specifications.
>> It makes sense to think that different specifications satisfy different
>> use cases, it is important to understand in which cases which technologies
>> are ideal.
>>
>> It appears that we have reached this understanding. Or, at least I hope
>> so.
>>
>> For any additional feedback, please share; the authors and I will ensure
>> nothing is overlooked.
>> best
>>
>> Giuseppe
>>
>>
>>
>>
>>
>> Il giorno mer 17 gen 2024 alle ore 19:07 Orie Steele
>>  ha scritto:
>>
>>> Hello Digital Credential Enthusiasts,
>>>
>>> See:
>>> https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
>>>
>>> Note the use of the term digital credential, and the alignment to CWT
>>> based credentials and CWT based credential status lists.
>>>
>>> As a quick summary of the editors draft above:
>>>
>>> It is basically a refresh-token-like approach to dynamic state, where
>>> the holder retrieves updated state from the issuer at regular intervals,
>>> and can then present that dynamic state directly to the verifier.
>>>
>>> This eliminates the herd privacy and phone home issues associated with
>>> W3C Bitstring Status Lists.
>>>
>>> And it informs the holder of dynamic state, so the digital wallet can
>>> provide a better user experience.
>>>
>>> However, an issuer (government or ngo) could use the interval of
>>> requesting dynamic state, to track the holder... so the guidance from
>>> https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
>>>
>>> Is also relevant to this draft.
>>>
>>> I also learned that
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
>>>
>>> Has defined a new property for expressing "Verifi

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

[Giuseppe De Marco]

This depends on the evaluation criteria of the verification you conduct
with a subject.

We can agree that the initial verifiable evidence that a Trust Anchor/CA
has issued a certificate for a subject is the first indication that the
subject belongs to a network/framework/shared-regulation/perimeter.

Let's consider this mailing list as a trust anchor.

We're having a productive conversation under a common trust anchor, where
the evidence that connects us is our membership in this community, under
the IETF Trust Anchor.

However, this alone is not sufficient, because you must read everything I
say and empirically evaluate if you can trust me qualitatively.

OpenID Federation allows the exchange of metadata to securely establish
interoperability and also applies policies that dynamically change this
metadata, adding qualitative evidence with trust marks.

This is the advancement I found that the X.509 based PKI was not designed
for. I use X.509 based PKI for other purposes, since in this universe
everything has its right place, and I appreciate this.

I also appreciate PIKA in a way to make this grow and get integrated with
other models that should not be kept out of the scope of the specification
if you agree and if we may have the opportunity to work together in this
field

Il giorno mer 12 giu 2024 alle ore 12:47 Rohan Mahy 
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
>>>&g

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

[Giuseppe De Marco]

Ciao Denis,

thank you for the time spent in reading and writing, I see several points
that express an enormous gratitude from me for your contribution.
I add my feedbacks below.

Il giorno mar 11 giu 2024 alle ore 18:12 Denis  ha
scritto:

>
> The text of the email states:
>
> "there are several use cases for revocations, each of which is addressed,
> either wholly or partially, in these specifications".
>
> While there are indeed several use cases for revocations, I don't believe
> that each of them can be addressed
> either wholly or partially in these specifications *to the best interest
> of the end-users*.
>

Yes, we're still on it. The sin I see is that we have started first with
technical solutions and specifications before having a clear view about the
legal and privacy requirements.
Something that we're still picking along the road. Regarding the technical
limitations of the current technologies: today I cannot get more than this.

*1) In section 3, a Holder is defined as* :
>
> Holder: An entity that receives Verifiable Credentials and has control
> over them to present them to the Verifiers as Verifiable Presentations.
>
> This definition is ambiguous as it may be understood to be a human-being
> (and it is the case later on ...) .
> The word "entity" should be changed into "application".
>

I remember an (hilarius) conversation made with Daniel Fett in Rome, during
the OSW, about the question mark <>.
Who is the Holder of the milk the user bought in the market: The fridge in
the house or the user that owns the fridge?

Despite the hilarious, but still philosofical, question, the definition of
holder was taken from the openid specs (
https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-terminology
)
This was made to not go too much far from something already shared, agreed
and developed within the community.


*2) The document should first identify the reasons for using a revocation
> mechanism*
>
>
In my context I have also the revocation request made by the user, and
other flows pertaining the revocation when made by authentic sources or
other authorities (jurisdicional ...).
The text today wants to define the approach to issue and verify status
assertions.

For the requirement to define a credential revocation request with the
credential issuer as the audience a brand new draft should born, since this
should be neutral with the status check if list of assertions.
good point anyway.


> The term "Wallet Instance" is being used and is defined on page 4 as:
>
> The digital wallet in control of a User, also known as Wallet.
>
> So let us consider the use case of a Wallet.
>
> The current document is directly focusing on a technical mechanism without
> telling what the problems to be solved are.
>

I can take this, good catch. I'd continue on this here:
https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/73


> Two entities can take the initiative of a revocation : either the owner of
> a wallet (i.e., not the Holder) or the Issuer.
>

as mentioned above, also a jurisdictional trusted party, or the wallet
provider that doesn't see the wallet instance no more compliant/secure.


>
>
> Let us focus about the owner of a wallet and its relationship with his
> wallet.
>
> The following situations can typically happen :
>
> (1) Where is my wallet ? I can't find it any more. Either I simply lost it
> or somebody has stolen it.
> (2) My wallet has indeed been stolen. I am sure about this, but I know
> that the thief is not in possession of the authentication factor(s) to use
> it.
> (3) My wallet has indeed been stolen and unfortunately I do know that the
> thief is in possession of the authentication factor(s) to use it.
>
>
good conversation. I want to clarify that these are consideration that not
necessarly could be included in the draft, since they go out of its scope.

1) the citizen can use an external service to be identified and therefore
ask to the wallet provider the revocation of its wallet instance
2) still weak due to the infinite ways to "use" an hardware/software in an
unconvetional way. The citizen still should ask the revocation ...
3) as the previous one


> For each of these cases, should the owner of a wallet ask the Issuer to
> revoke of his digital credential ?
>
> In the first case (1), let us suppose that the digital credential is
> revoked. Using the Status Assertion mechanism, the revocation will remain
> valid
> approximately 24 hours. If five minutes after successfully asking the
> revocation of that digital credential, the lost wallet is found again,
> the digital credential cannot be used during the next 24 hours. A new
> digital credential request must then be initiated.
> If a suspension mechanism were available, the new digital credential
> request would be avoided.
>
> In the case (2), if the Wallet has been found again a similar situation
> applies.
> If a suspension mechanism were available, the new digital credential
> 

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

[Giuseppe De Marco]

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-WG] Re: Call for adoption - PIKA

[Giuseppe De Marco]

Hey Richard,

My reply was very verbose, thank you for the time spent in reading it.

The problem I see in the communities around the openid/ietf/any-other
technical specification is the way we use the term trust and how we aim to
achieve trust from a technical perspective.

I can show that my name is Giuseppe (subject id) and that you are talking
exclusively with me (secure cryptographic material exchange and
confidentiality in transaction) but this doesn't solve the problem we want
to solve through a trust establishment, because identity and key
attestations doesn't give us any trust.

As mentioned by Mike, OpenID Connect Core implementations already uses TLS
and subject id comparisons to achieve this.

The example of the surgery made with the chainsaw is something already
heard by architects that have implemented SAML2 and that reluctant to move
to OAuth 2.0. They said <> or <>.
Several years was spent to demonstrate why OAuth 2.0 was designed in a way
to satisfy several design principles about scalability and specialization
of the endpoints to specific functionalities.

I can only help, where needed or requested, to demystifying the complexity
of the relationships willing to find trust (in this context, at least, from
a technical pespective only) and be sure that who is going to create new
specifications is aware of the previous ones, of the problem that he's
trying to solve and recognize what is intentionally excluded from the scope.

I would like to continue this conversation with the will to merge the
openid federation approach and the PIKA that I see an important
specification to create a bridge to the X.509 world.
this also requires trust and reducing conflict between authors and
consequently between specifications I believe is an intrinsic goal of our
community.

If I had a little more time...

Il giorno mar 11 giu 2024 alle ore 05:09 Richard Barnes  ha
scritto:

> Hi Giuseppe,
>
> To be blunt, solving the use cases we're talking about with OpenID
> Federation is like doing surgery with a chainsaw.  You might achieve the
> intended goal, but the results will be messy.
>
> The trust model we are addressing is one that already exists: A JWT is
> issued by an issuer identified by a URL, and the relying party needs to get
> keys that are verifiable associated with that issuer's URL.  The only thing
> we are doing is trading HTTPS for JWT signing for how that verifiable
> association is made.  It is explicitly *not* a federated model; X.509 is
> already baked into it and does the job well.
>
> Your first point is a good one, though.  It could be a good idea to have
> an indicator here of how the issuer intends the keys to be used (for
> issuing ID tokens vs. Verifiable Credentials, say).  Happy to have that
> filed as a first issue on an adopted document.
>
> Cheers,
> --Richard
>
>
> On Mon, Jun 10, 2024 at 6:50 PM Giuseppe De Marco 
> wrote:
>
>> Hi,
>>
>> I appreciate the introduction of PIKA, which demonstrates a commitment to
>> addressing current challenges. However, I have identified some key areas of
>> concern that need attention:
>>
>> 1. The current documentation lacks clarity regarding the number and scope
>> of cryptographic keys, particularly in terms of their intended use across
>> different protocols. Given that an issuer can serve multiple roles, such as
>> an authorization server, a credential issuer, or a relying party issuing
>> signed request objects, it is important to consider the benefits of using
>> distinct, specialized keys for different protocols and roles and how PIKA
>> would propose a model to achieve this.
>>
>> 2. We already have a mechanism to bring multiple public keys, for
>> multiple scopes/protocols, in a chain of signed JWT. This is OpenID
>> Federation which doesn't depend to X.509 but at the same time is able to
>> distribute also X.509 certificates using the `x5c` claim within the jwk
>> claims and for legacy applications. I believe that this last point is
>> important, since I see X.509 as a requirement only for legacy applications.
>> I would not design a new infrastructure using X.509 as a foundamental
>> requirement for a trust framework.
>>
>> 3. I kindly suggest to clarify which is the meaning/intention of the term
>> trust, from which kind of perspective PIKA aims to approach the mechanisms
>> of the trust evaluations and for which trust topology (federative, end to
>> end, hybrid ...), the roles of the trust authorities or trusted third
>> parties and so on.
>>
>> 4. I read that PIKA reuses the same requirements of openid federation.
>> Probably this needs more clarifications. OpenID Federation provides a
>> mechanism to establish the trust to a subject and obtain its public k

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

[Giuseppe De Marco]

Hi,

I appreciate the introduction of PIKA, which demonstrates a commitment to
addressing current challenges. However, I have identified some key areas of
concern that need attention:

1. The current documentation lacks clarity regarding the number and scope
of cryptographic keys, particularly in terms of their intended use across
different protocols. Given that an issuer can serve multiple roles, such as
an authorization server, a credential issuer, or a relying party issuing
signed request objects, it is important to consider the benefits of using
distinct, specialized keys for different protocols and roles and how PIKA
would propose a model to achieve this.

2. We already have a mechanism to bring multiple public keys, for multiple
scopes/protocols, in a chain of signed JWT. This is OpenID Federation which
doesn't depend to X.509 but at the same time is able to distribute also
X.509 certificates using the `x5c` claim within the jwk claims and for
legacy applications. I believe that this last point is important, since I
see X.509 as a requirement only for legacy applications. I would not design
a new infrastructure using X.509 as a foundamental requirement for a trust
framework.

3. I kindly suggest to clarify which is the meaning/intention of the term
trust, from which kind of perspective PIKA aims to approach the mechanisms
of the trust evaluations and for which trust topology (federative, end to
end, hybrid ...), the roles of the trust authorities or trusted third
parties and so on.

4. I read that PIKA reuses the same requirements of openid federation.
Probably this needs more clarifications. OpenID Federation provides a
mechanism to establish the trust to a subject and obtain its public keys
and not only this, since it allow a secure interoperability through a
secure metadata exchange and also the distribution of compliance assertions
called trust marks.

5. The trust model proposed in PIKA relies fundamentally on a WWW CA
(Certificate Authority) for purposes beyond its original design.
Specifically, assessing compliance with shared rules, such as a trust
framework or national regulations, falls outside the scope of WWW X.509
CAs. Consequently, using this type of binding to establish a higher level
of trust may not be appropriate. The use of the term "trust" in this
context could potentially be misleading. It would be beneficial to
reconsider the terminology and mechanisms used to better align with the
intended functions and limitations of the technologies employed.

therefore,

I would therefore suggest defining the terms trust and trust model, and the
purposes of the specification in relation to these.
Then list the problems that this specification intends to solve and the
requirements identified by it.

If it is trust and the mechanisms for validating trust in relation to
common elements or properties between different entities (and mutual
recognition) we could start working on common elements already well
established in openid federation and that they could be further explored
with your contribution and requirements.

>From my side, I find the use of openid federation as a broad-based solution
evident. Today I am having a positive conversation with other authors about
the birth of two new drafts dedicated to openid federation and I believe
that this is a good time to join forces to build something together with
strong harmonizations, not just some endpoint picking.

>From my perspective Iam probably more interested in understand what
obstacles you have found in using federation and what additional features
or endpoints you intend to use to satisfy your requirements that, in fact,
I would mark with greater determination within the draft.

Even If I read it with pleasure and curiosity, appreciating the work and
the effort spent of it, I look forward to receiving more information here
in this thread from the pika's authors.
Currently, I am hesitant to support this specification as it requires
additional time and comparative analysis before I can evaluate it
positively.

Thank you for sharing and for the work made todate
Giuseppe

Il giorno lun 10 giu 2024 alle ore 13:48 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> All,
>
> This is an official 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 *June 24th*.
>
> 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-WG] Re: OAuth Digital Credential Status Attestations

[Giuseppe De Marco]

Hello Everybody,

OAuth Status Assertions replaces OAuth Status Attestations and it is
published here:
https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/

Therefore here its html preview:
https://www.ietf.org/archive/id/draft-demarco-oauth-status-assertions-00.html

Compared to the previous draft, the change in the draft name reflects the
feedback received on the mailing list, for which I am very grateful.
The work continues and tomorrow there will be an engaging discussion about
the new drafts concerning revocations, including status assertions, status
lists, and OAuth global token revocation, during the OAuth interim meeting.

>From my understanding, there are several use cases for revocations, each of
which is addressed, either wholly or partially, in these specifications.
It makes sense to think that different specifications satisfy different use
cases, it is important to understand in which cases which technologies are
ideal.

It appears that we have reached this understanding. Or, at least I hope so.

For any additional feedback, please share; the authors and I will ensure
nothing is overlooked.
best

Giuseppe





Il giorno mer 17 gen 2024 alle ore 19:07 Orie Steele
 ha scritto:

> Hello Digital Credential Enthusiasts,
>
> See:
> https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
>
> Note the use of the term digital credential, and the alignment to CWT
> based credentials and CWT based credential status lists.
>
> As a quick summary of the editors draft above:
>
> It is basically a refresh-token-like approach to dynamic state, where the
> holder retrieves updated state from the issuer at regular intervals, and
> can then present that dynamic state directly to the verifier.
>
> This eliminates the herd privacy and phone home issues associated with W3C
> Bitstring Status Lists.
>
> And it informs the holder of dynamic state, so the digital wallet can
> provide a better user experience.
>
> However, an issuer (government or ngo) could use the interval of
> requesting dynamic state, to track the holder... so the guidance from
> https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
>
> Is also relevant to this draft.
>
> I also learned that
> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
>
> Has defined a new property for expressing "Verifiable Credential" "type"
> `vct`, which is different from how W3C defines credential types.
>
> W3C uses the expanded IRI for the graph node type, based on the JSON-LD
> context.
>
> For example with:
>
> {
>   "@context": [
> "https://www.w3.org/ns/credentials/v2;,
> "https://www.w3.org/ns/credentials/examples/v2;
>   ],
>   "id": "http://university.example/credentials/1872;,
>   "type": ["VerifiableCredential", "ExampleAlumniCredential"],
>   ...
> }
>
> The credential type in RDF becomes "
> https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential;
>
> Which is different from "ExampleAlumniCredential" in JSON... More evidence
> that RDF leads to developer confusion regarding safe typing.
>
> The OAuth solution does not have this confusing issue, they set the type
> explicitly:
>
> {
>  "vct": "https://credentials.example.com/identity_credential;,
>  "given_name": "John",
>  "family_name": "Doe",
>  "email": "john...@example.com",
>  "phone_number": "+1-202-555-0101",
>  "address": {
>"street_address": "123 Main St",
>"locality": "Anytown",
>"region": "Anystate",
>"country": "US"
>  },
>  "birthdate": "1940-01-01",
>  "is_over_18": true,
>  "is_over_21": true,
>  "is_over_65": true,
>  "status": {
> "status_attestation": {
> "credential_hash_alg": "S256",
> }
>  }
> }
>
> 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
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Second WGLC for OAuth 2.0 Protected Resource Metadata

[Giuseppe De Marco]

+1 for publication

Il giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> All,
>
> This is a *second* *WG Last Call* for the *OAuth 2.0 Protected Resource
> Metadata* document (the previous one was for v03.).
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *May 29*.
> If you reviewed the document and you do not have any comments or concerns,
> it would be great if you can reply to this email indicating that.
>
> 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-WG] Re: I-D Action: draft-ietf-oauth-v2-1-11.txt

[Giuseppe De Marco]

Thank you Aaron, great work
+1

Il mer 15 mag 2024, 02:29 Aaron Parecki 
ha scritto:

> Hi all,
>
> Thanks for the productive discussion at the interim meeting today. I've
> taken the feedback and published a new version with all the changes
> discussed.
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-11.html
>
> Please review the diff here:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-v2-1-11
>
> As mentioned on the call, there are still more issues to discuss. Please
> feel free to chime in on the github issues!
> https://github.com/oauth-wg/oauth-v2-1/issues
>
> Aaron
>
> On Tue, May 14, 2024 at 5:14 PM  wrote:
>
>> Internet-Draft draft-ietf-oauth-v2-1-11.txt is now available. It is a work
>> item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>>
>>Title:   The OAuth 2.1 Authorization Framework
>>Authors: Dick Hardt
>> Aaron Parecki
>> Torsten Lodderstedt
>>Name:draft-ietf-oauth-v2-1-11.txt
>>Pages:   96
>>Dates:   2024-05-14
>>
>> Abstract:
>>
>>The OAuth 2.1 authorization framework enables an application to
>>obtain limited access to a protected resource, either on behalf of a
>>resource owner by orchestrating an approval interaction between the
>>resource owner and an authorization service, or by allowing the
>>application to obtain access on its own behalf.  This specification
>>replaces and obsoletes the OAuth 2.0 Authorization Framework
>>described in RFC 6749 and the Bearer Token Usage in RFC 6750.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-11.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-v2-1-11
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> ___
>> 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

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Giuseppe De Marco]

Ciao Rifaat and everybody,

In Italy, I've come across two national guidelines[1][2] that utilize OAuth
2.0 for protecting resources. These were implemented two years ago when the
draft was still an individual draft and not as mature as it is today.
Reflecting on the Italian implementation experience, the most significant
insights can be distilled into two main points:

1. The core components outlined in the Italian guidelines remain consistent
with those in the current OAuth specification, demonstrating that this
specification was already consistent, durable and relevant.
2. Despite its status as an I-D at the time, the specification met our
needs perfectly. It provided the necessary framework that, in its absence,
would have likely led to the development of a similar solution.

For these reasons, I am convinced that OAuth 2.0 for protected resources
should be standardized. My gratitude goes out to the authors for their
foundational work and to everyone involved for their valuable revisions.

Regards,
Giuseppe De Marco

[1] https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html
[2]
https://www.agid.gov.it/sites/default/files/repository_files/llgg_attribute_authorities_0.pdf

Il giorno mer 27 mar 2024 alle ore 13:54 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> All,
>
> This is a *WG Last Call* for the *OAuth 2.0 Protected Resource Metadata*
> document.
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *April 12*.
>
> Regards,
>   Rifaat & Hannes
> ___
> 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

[Giuseppe De Marco]

I missed this

> IMO, neither the "Token Status List", nor to the "OAuth Status
Attestations" are the right way to address two privacy considerations:
"Unlinkability between verifiers" and "Untrackability by digital credential
issuers".

here my notes

*Unlinkability between verifiers*
Status Attestations are designed to be privacy-preserving by not requiring
verifiers to gather any additional information from third-party entities.
This means that each verifier independently verifies the status of a
digital credential, though the status attestation, without needing to
interact with or reveal information to other verifiers or third-party
status list providers. This approach ensures that actions performed by one
verifier cannot be linked to actions performed by another verifier,
maintaining unlinkability between them.

*Untrackability by digital credential issuers*
Since Status Attestations can be verified statically without further
communication with the credential issuer or any other party, the issuer
cannot track when or where the digital credential is being verified. This
is in contrast to models where the verifier must query a central status
list or the issuer directly, which would allow the issuer to track the
usage of the digital credential. By providing all necessary information
within the Status Attestation itself, it ensures that the issuer cannot
track the verification activities related to a specific digital credential.

These mechanisms are integral to the design of OAuth Status Attestations,
aiming to enhance privacy and security in the verification of digital
credentials by minimizing potential privacy risks associated with the
verification process

thank you for having solicitated these aspects, I'll brings these few notes
in the privacy consideration section as well,
really appreciate your mindset Denis,
best

Il giorno mer 7 feb 2024 alle ore 14:12 Giuseppe De Marco <
demarco...@gmail.com> ha scritto:

> Ciao Denis,
>
> I agree with you until I find that the presentation/credential format has
> the feature to attest its (non-)revocation. I was a BLS signature
> evangelist at least two years ago. Working in the government field, I am
> now required to use formats that are globally recognized and standardized
> (please don't delve into this; I mentioned it just to be honest with you).
>
> According to this awareness, we, along with other authors and
> implementers, need a revocation checking mechanism that is agnostic to the
> format and scope of the subject to which the status is attested and
> completely privacy preserving.
>
> Both Status Lists and Status Attestations are suitable for different use
> cases and solve specific problems. That's why they exist, taking into
> account the design principle of being agnostic to the subject format.
> Merging them into a single draft would be the ideal solution. However, if
> this is not possible and at the same time people require an OCSP
> stapling-like approach, OAuth Status Attestations are justified in their
> existence.
>
> I took your notes:
>
> - todo: privacy considerations section
> - A policy identifier included in a digital credential would indicate that
> this digital credential, when stored in a wallet, is still under the
> control of its digital credential issuer.
>
> I'll put my hands on the specs before IETF in brisbane (asap).
>
> If you're interested in improving this brand-new specification and
> considering how you might implement it, any contribution from your side is
> appreciated and will be taken into account, both now and in the future. To
> ensure your contributions are not lost in email threads, please consider
> opening issues here:
> https://github.com/peppelinux/draft-demarco-oauth-status-attestations/issues
>
> I just open several issue to keep track of your hints,
> thank you Denis!
>
> Il giorno mer 7 feb 2024 alle ore 12:12 Denis  ha
> scritto:
>
>> Hi Giuseppe,
>>
>> We are on different tracks.
>>
>> There is however a common point in our two approaches: "however, we
>> assume that the Wallet Instance had an internet connection within the last
>> 24h".
>> However, there is no need to present an "OAuth Status Attestation" to a
>> verifier.
>>
>> IMO, neither the "Token Status List", nor to the "OAuth Status
>> Attestations" are the right way to address two privacy considerations:
>> "Unlinkability between verifiers" and "Untrackability by digital
>> credential issuers".
>>
>> Anyway, none of these two approaches would be usable with digital
>> credentials signed using BBS+.
>> A single solution able to work in all cases would be preferable.
>>
>> It can be 

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

[Giuseppe De Marco]

Ciao Denis,

I agree with you until I find that the presentation/credential format has
the feature to attest its (non-)revocation. I was a BLS signature
evangelist at least two years ago. Working in the government field, I am
now required to use formats that are globally recognized and standardized
(please don't delve into this; I mentioned it just to be honest with you).

According to this awareness, we, along with other authors and implementers,
need a revocation checking mechanism that is agnostic to the format and
scope of the subject to which the status is attested and completely privacy
preserving.

Both Status Lists and Status Attestations are suitable for different use
cases and solve specific problems. That's why they exist, taking into
account the design principle of being agnostic to the subject format.
Merging them into a single draft would be the ideal solution. However, if
this is not possible and at the same time people require an OCSP
stapling-like approach, OAuth Status Attestations are justified in their
existence.

I took your notes:

- todo: privacy considerations section
- A policy identifier included in a digital credential would indicate that
this digital credential, when stored in a wallet, is still under the
control of its digital credential issuer.

I'll put my hands on the specs before IETF in brisbane (asap).

If you're interested in improving this brand-new specification and
considering how you might implement it, any contribution from your side is
appreciated and will be taken into account, both now and in the future. To
ensure your contributions are not lost in email threads, please consider
opening issues here:
https://github.com/peppelinux/draft-demarco-oauth-status-attestations/issues

I just open several issue to keep track of your hints,
thank you Denis!

Il giorno mer 7 feb 2024 alle ore 12:12 Denis  ha
scritto:

> Hi Giuseppe,
>
> We are on different tracks.
>
> There is however a common point in our two approaches: "however, we assume
> that the Wallet Instance had an internet connection within the last 24h".
> However, there is no need to present an "OAuth Status Attestation" to a
> verifier.
>
> IMO, neither the "Token Status List", nor to the "OAuth Status
> Attestations" are the right way to address two privacy considerations:
> "Unlinkability between verifiers" and "Untrackability by digital
> credential issuers".
>
> Anyway, none of these two approaches would be usable with digital
> credentials signed using BBS+.
> A single solution able to work in all cases would be preferable.
>
> It can be supported by including an additional field in a digital
> credential: a policy identifier.
>
> A policy identifier included in a digital credential would indicate that
> this digital credential, when stored in a wallet, is still under the
> control of its digital credential issuer.
>
> An I-D would be necessary (and sufficient) to define such policy
> identifier.
>
> Denis
>
> Ciao Denis,
>
> OAuth Status Attestation was born because of some different approches with
> the oauth status list token, I really would like to have a single
> specification with the two approaches.
>
> I report below and explain the main differences between the status
> attestation and the status list token.
>
> Taken from status list editor's copy draft
> >  This (Status List Token) allows for the Status List Token to be hosted
> by third parties or be transferred for offline use cases.
>
> it is not clear how:
>
> - the token is rquested and obtained and used
> - why it would be hosted by a third party
> - the meaning of "transferred"
>
> AFAIK this token reference a status list, with url and index, allowing a
> RP to control over time the status of a credential.
> It is not clear the scope of this token, in my assumption it represent a
> long lived attestation of the historical status of a credential and that's
> fine, but doesn't protect user privacy against revocation status checks
> over time by unallowed RP.
>
> Here the summary of the razionale behind OAuth Status Attestation
>
> Use Case Scenario:
> - A Verifier needs to check the status of a given Credential only during
> the presentation flow.
> - A Verifier is not allowed to check the status of a Credential over time
> (after it was presented by the Holder), due to some privacy constraints.
> - No internet connection is available during the presentation phase
> (however, we assume that the Wallet Instance had an internet connection
> within the last 24h).
>
> The idea:
> The Credential Issuer provides the Wallet Instance with a Status
>  Attestation, which is bound to a Digital Credential.  This allows the
> Wallet Instance to present it, along with the Digital Credential itself, to
> a Verifier as proof of the Digital Credential's non-revocation.
>
> Merging the two approaches or extending OAuth Status List with OAuth
> Status Attestations is always possibile if the authors wants do this, I
> want do this if resonable to you and the 

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

[Giuseppe De Marco]

Ciao Denis,
OAuth Status Attestation was born because of some different approches with
the oauth status list token, I really would like to have a single
specification with the two approaches.

I report below and explain the main differences between the status
attestation and the status list token.

Taken from status list editor's copy draft
>  This (Status List Token) allows for the Status List Token to be hosted
by third parties or be transferred for offline use cases.

it is not clear how:

- the token is rquested and obtained and used
- why it would be hosted by a third party
- the meaning of "transferred"

AFAIK this token reference a status list, with url and index, allowing a RP
to control over time the status of a credential.
It is not clear the scope of this token, in my assumption it represent a
long lived attestation of the historical status of a credential and that's
fine, but doesn't protect user privacy against revocation status checks
over time by unallowed RP.

Here the summary of the razionale behind OAuth Status Attestation

Use Case Scenario:
- A Verifier needs to check the status of a given Credential only during
the presentation flow.
- A Verifier is not allowed to check the status of a Credential over time
(after it was presented by the Holder), due to some privacy constraints.
- No internet connection is available during the presentation phase
(however, we assume that the Wallet Instance had an internet connection
within the last 24h).

The idea:
The Credential Issuer provides the Wallet Instance with a Status
 Attestation, which is bound to a Digital Credential.  This allows the
Wallet Instance to present it, along with the Digital Credential itself, to
a Verifier as proof of the Digital Credential's non-revocation.

Merging the two approaches or extending OAuth Status List with OAuth Status
Attestations is always possibile if the authors wants do this, I want do
this if resonable to you and the WG as well,
best




Il giorno mer 7 feb 2024 alle ore 09:03 Denis  ha
scritto:

> Hi Guiseppe,
>
> In your reply, you cut the main content of my original text and hence you
> didn't reply to it.
>
> In addition, you missed to pay attention to the email I sent yesterday in
> my response to "I-D Action: draft-ietf-oauth-status-list-01.txt".
>
> I copy some parts of it below:
>
> 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 credential issued by that digital credential issuer will be
> frozen by the Holder.
> As a consequence, *if a digital credential has been able to be used by a
> Holder, this means that it has not been frozen*.
> A digital credential can later be unfrozen by its digital credential
> issuer.
>
> If there is a desire to freeze all the digital credentials stored in an
> app, the TA Manager of that app would be in a position to do that.
>
> In the context of the “Issuer-Holder-Verifier model”, the above
> descriptions are sketches of possible approaches that highlight the fact
> that,
> the "Token Status List" approach might not be the best way, nor the
> simplest way, to support the two following privacy properties:
> “Unlinkability between verifiers“ and “Untrackability by digital
> credential issuers”.
>
> 

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

[Giuseppe De Marco]

1. 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 45 from COM(2021) 281 final, (
>>>> https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52021PC0281)
>>>> there is the following statement:
>>>> >>>
>>>> >>>"  A strengthened privacy-by-design approach could yield
>>>> additional benefits since the wallet would not require intermediaries
>>>> >>> in the process of asserting the attributes, thus
>>>> enabling the citizen to communicate directly with the service and
>>>> credential providers".
>>>> >>>
>>>> >>> Every IETF draft now includes both a Security Consideration section
>>>> and a Privacy Consideration section. There is no such sections in ARF 
>>>> 1.0.X.
>>>> >>>
>>>> >>> Since ARF 1.0.X has not listed any privacy principle, it could not
>>>> follow a privacy-by-design approach.
>>>> >>>
>>>> >>>
>>>> >>> Before defining technical solutions, requirements would first need
>>>> to be identified and agreed. At the moment, none of the five experiments is
>>>> considering
>>>> >>> the previously identified privacy principles (nor the above
>>>> security consideration).
>>>> >>>
>>>> >>> There should first be an agreement to add both a Security
>>>> Consideration section and a Privacy Consideration section to the ARF.
>>>> >&

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

[Giuseppe De Marco]

Hi Denis,

sorry for the delay, below by points.

> A *digital credential* may be presented to a verifier long after it has
been issued.

In the abstract we say what's the status attestation. Probably it's an
editorial suggestion from you to say what's the substantial difference
between the digital credential and its status attestation. the subject of
this specification is the status attestation, not the digital credential
which the status attestation is referred to.

> Entity that relies on the validity of the *digital proof* presented to
it.

verifiers validate the digital credentials and these can have different
revocation check mechanisms (or no one). I'd keep the digital credential as
the most important landmark for the verifier, where the status attestation
is a sort of annex of that.

> This does not correspond to the flows of the figure.

The picture contains two distinc moments: the provisioning of the
attestation (that currently in the specs is online only) and the
presentation of it (that wors fine in the offline scenario).

I'll look forward for other interactions about this specs, probably by
voice it would be everything more easy to explain,
thank you for the hints!
best
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IETF119 - Call for topics

[Giuseppe De Marco]

Ciao Rifaat,

John will present the following draft at the next IETF meeting.
After that we would like to do a call for adoption as a WG item.

https://github.com/peppelinux/draft-demarco-cose-header-federation-trust-chain

best

Il giorno mar 30 gen 2024 alle ore 23:00 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> This is a reminder to send us your topics for Brisbane, to help us plan
> properly!
>
> Regards,
>  Rifaat & Hannes
>
>
> On Thu, Jan 25, 2024 at 1:44 PM Michael Jones 
> wrote:
>
>> Please put time on the agenda to discuss
>> draft-ietf-oauth-resource-metadata.
>>
>>
>>
>> Thanks,
>>
>> -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
>> *Sent:* Wednesday, January 24, 2024 6:15 AM
>> *To:* oauth 
>> *Subject:* [OAUTH-WG] IETF119 - Call for topics
>>
>>
>>
>> All,
>>
>>
>>
>> This is a call for topics for the coming IETF119 in Brisbane.
>>
>>
>>
>> Please, let us know *as soon as possible *if you have topics that you
>> would like to discuss.
>>
>> This will help us request enough sessions to address the requested topics.
>>
>>
>>
>> *Note that if we do not get the list before Feb 2nd, we might request
>> less sessions than we usually do.*
>>
>> *This might impact the time allocated to each topic or might force us to
>> drop some topics.*
>>
>>
>>
>> Regards,
>>
>>  Rifaat & Hannes
>>
>>
>>
>>
>>
>>
>>
> ___
> 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)

[Giuseppe De Marco]

Ciao Denis,

thank you for the quick reply and for your contribution.
The scope of the current draft is to provide a verifiable artifact that
give the proof that a specific credential is active, then not revoked.

>From your sequence diagram I read a digital credential issuance, while this
is not in the scope of the draft.
best


Il giorno gio 18 gen 2024 alle ore 10:26 Denis  ha
scritto:

> 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 privacy issues the wallet ecosystem has;
> - it would interesting mentioning in the introduction that's pratically an
> ocsp stapling like mechanism, just to give some 

Re: [OAUTH-WG] OAuth Digital Credential Status Attestations

[Giuseppe De Marco]

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 privacy issues the wallet ecosystem has;
- it would interesting mentioning in the introduction that's pratically an
ocsp stapling like mechanism, just to give some context (credit: Paul
Bastien);
- The Rationale section needs to clarify better problems and solutions, where
it seems that the problem does not exist or that it is weak. A review is
necessary to clearly bring the benefits;
- Editorials mistake are still along the reading.

thank you for your time and interest,
best






Il giorno mer 17 gen 2024 alle ore 21:06  ha scritto:

> Hi Guiseppe, Francesco, Orie,
>
>
>
> @Orie: Thanks for sharing the draft.
>
>
>
> As a quick reaction: It would be good to invent a new term for
> “attestation” in draft-demarco-status-attestations.html because this term
> is already widely used in a different context (see RFC 9334).
>
>
>
> @Guiseppe and Francesco: It would be great if you could submit your draft
> to OAuth or SPICE for discussion.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* OAuth  *On Behalf Of *Orie Steele
> *Sent:* Mittwoch, 17. Jänner 2024 19:07
> *To:* sp...@ietf.org
> *Cc:* oauth 
> *Subject:* [OAUTH-WG] OAuth Digital Credential Status Attestations
>
>
>
> Hello Digital Credential Enthusiasts,
>
> See:
> https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
>
> Note the use of the term digital credential, and the alignment to CWT
> based credentials and CWT based credential status lists.
>
> As a quick summary of the editors draft above:
>
> It is basically a refresh-token-like approach to dynamic state, where the
> holder retrieves updated state from the issuer at regular intervals, and
> can then present that dynamic state directly to the verifier.
>
> This eliminates the herd privacy and phone home issues associated with W3C
> Bitstring Status Lists.
>
> And it informs the holder of dynamic state, so the digital wallet can
> provide a better user experience.
>
> However, an issuer (government or ngo) could use the interval of
> requesting dynamic state, to track the holder... so the guidance from
> https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
>
> Is also relevant to this draft.
>
> I also learned that
> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
>
> Has defined a new property for expressing "Verifiable Credential" "type"
> `vct`, which is different from how W3C defines credential types.
>
> W3C uses the expanded IRI for the graph node type, based on the JSON-LD
> context.
>
> For example with:
>
> {
>   "@context": [
> "https://www.w3.org/ns/credentials/v2;,
> "https://www.w3.org/ns/credentials/examples/v2;
>   ],
>   "id": "http://university.example/credentials/1872;,
>   "type": ["VerifiableCredential", 

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

[Giuseppe De Marco]

Very interesting work, it reminds me the SPID Attribute Authorities,
where the users give their consent during the authentication, granting the
RPs to consume RS on behalf of users

the AS/OP issues several grant tokens (JWT Embedded Tokens) as many consent
give by the user to each Attribute Authority (RS).
Each grant token represents the verifiable proof of the consent given by
the user.
The RP uses these grant tokens with the specific audience (AS) to exchange
(STS) the grant token with a brearer or a DPoP Access Token, to be used to
consume the RS.

since this identity chaining is in line with the work made in Italy with
the Attribute Authorities, or shows several point in common, I'm very happy
to support this work and also I'd like to find with the help of the authors
the commons elements between what we have implemented in Italy and this
brand new specification.

ad maiora

Il giorno mar 14 nov 2023 alle ore 13:59 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> 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://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Giuseppe De Marco]

Hi,

everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for
different projects and orgs, I have included secured web cookie in
the recipe.
For the implementation profile of OpenID4VP I did the same, where the
secured and httponly cookie is used an in particular as a basic security
requirement for the cross device flow [1].

Even if I got perfectly Daniel's and Aaron's editorial strategy and I
agree, I think that Dick's proposal and your confirmation on that, Neil, is
something to take into account to bring developers awareness during the
implementation phases.
A ref to living OWASP specs surrounded by a generic refs to the user agent
security, even if out of scope, I think that should be in the specs.

[1]
https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow

Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden 
ha scritto:

> Although I think we could add some basic advice, the list of security
> headers to use is still evolving. For example, there were several headers
> added after Spectre to limit cross-site interactions. And then there’s
> things like the “X-XSS-Protection” header, which was best practice to add
> to responses not too long ago but has now been universally removed from
> browsers as it enabled certain content disclosure attacks.
>
> Cookie security attributes are perhaps a bit more stable, but in general
> we probably just want to point people at “living” guidance like OWASP.
>
> — Neil
>
> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
>
> The cookie and header recommendations I am thinking of would be for the AS
> as well as the client.
>
> A number of XSS attacks can be thwarted by a modern browser and the right
> HTTP headers.
>
> My question is: Did the authors consider adding cookie and header
> recommendations, and decided it was too general?
>
> Cookie and header best security practices have been around for years --
> I'm not suggesting we make anything up -- I'm suggesting we raise
> awareness.
>
> I consider myself to be fairly security aware, and I was not aware of some
> of the HTTP headers that are best security practice.
>
> /Dick
>
>
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> I don't think it's necessary to say "do the right things with cookies" in
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how
>> different browser-based architectures work with cookies so that seems like
>> a better place to actually have a real discussion about it.
>>
>> Also +1 to what Daniel said about not continuing to add little things.
>> Plus I think it's too late anyway, publication has already been requested
>> for the Security BCP.
>>
>> Aaron
>>
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett > 40danielfett...@dmarc.ietf.org> wrote:
>>
>>> I agree with Aaron!
>>>
>>> Also we should be very careful about any additions to the Security BCP
>>> at this point. It is very easy to re-start the "one more thing" loop we've
>>> been stuck in for the last years. There may be more useful things to say,
>>> but we should put them on the list for a future second version of the BCP.
>>>
>>> -Daniel
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>>>
>>> I don't think the Security BCP should incorporate cookie best practices
>>> directly in the document. If anything, it sounds like possibly a candidate
>>> for inclusion in the Browser Apps BCP.
>>>
>>> There are already some mentions of these cookie properties mentioned in
>>> the Browser Apps BCP, though only in reference to specific architectures,
>>> not as a general best practice. For example:
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>>>
>>> Aaron
>>>
>>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>>>
 Hey

 I was reviewing security on some sites I managed and checked to see if
 the recommendations were in the BCP.

 I don't see anything around cookies such as httpOnly, sameSite, secure.

 I saw some HTTP security header suggestions buried in 4.16
 (X-Frame-Options, CSP), but not for Strict-Transport-Security,
 Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
 rather vague.

 I understand these are general web security best practices, and perhaps
 I missed it, but I think it would be useful to call out that best security
 practices around cookies and headers should also be followed in Section 2,
 and either have the best practices included, or direct the reader where to
 find them.

 /Dick

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>>
>>> ___
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>> ___

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

[Giuseppe De Marco]

I support the adoption

Regards

Il sab 30 set 2023, 14:53 Rifaat Shekh-Yusef  ha
scritto:

> All,
>
> This is an official call for adoption for the *JWT and CWT Status List*
> draft:
> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/
>
> Please, reply *on the mailing list *and let us know if you are in *favor *
> or* against *adopting this draft as WG document, by *Oct 13th*.
>
> Regards,
>  Rifaat & Hannes
> ___
> 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 and JWT/VC documents

[Giuseppe De Marco]

Ciao Rifaat

I can say in the vest of an implementer, that VC documents are like
unrequited love, you know you need it but it's not something you can build
on.

Here I represent many organizations that are working to build on these,
with deadlines.

I express my strong support for these brand new specs, since I Need them
and I share the vision behind them. All about how these can became reality
would be search and found in a OAuth WG that would show how this would be
then possible.

I support the adoption and I'm implementing the so called vcstuff drafts

Il ven 29 set 2023, 20:16 Rifaat Shekh-Yusef  ha
scritto:

> There are two reasons for not calling for the adoption of this document:
> 1. The SPICE discussion, which gave the impression that the plan is to
> migrate this to a new dedicated WG.
> 2. Some people questioned whether this is in scope or not.
>
> If the first one is not an issue, and there is no plan to migrate this to
> a different WG, then we can definitely start a call for adoption and see
> what happens.
>
> Regards,
>  Rifaat
>
>
> On Fri, Sep 29, 2023 at 1:42 PM Kristina Yasuda  40microsoft@dmarc.ietf.org> wrote:
>
>> +1 to Brian’s and Orie’s observations.
>>
>>
>>
>> During last IETF, a question was asked whether
>> draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of
>> OAuth WG charter or not. A lot of comments observed that it is because as
>> Brian has succinctly put it “a general JWT status/revocation mechanism (as
>> defined in this draft) would fall easily within the remit of the WG as is”.
>>
>>
>>
>> I also agree that it seems that focus has been unintentionally shifted
>> away from working on this status list draft, which there is an interest and
>> a need from the implementers to work on it. It would be great if we can
>> discuss and agree whether this draft is in scope for oauth wg or not and if
>> so whether we can start the call for adoption.
>>
>>
>>
>> Best,
>>
>> Kristina
>>
>>
>>
>> *From:* Orie Steele 
>> *Sent:* Friday, September 29, 2023 10:35 AM
>> *To:* Brian Campbell 
>> *Cc:* Torsten Lodderstedt ; torsten=
>> 40lodderstedt@dmarc.ietf.org; Kristina Yasuda <
>> kristina.yas...@microsoft.com>; oauth ; Paul Bastian <
>> paul.bast...@bdr.de>; Christian Bormann <
>> christiancarl.borm...@de.bosch.com>
>> *Subject:* Re: [OAUTH-WG] OAuth and JWT/VC documents
>>
>>
>>
>> Inline:
>>
>>
>>
>> On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>
>>
>> If I might offer an observation...
>>
>>
>>
>> The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*])
>> really just a generic status/revocation checking mechanism for JWTs in
>> general. Given the history/lineage of JWT development within the OAuth WG,
>> it seems like a general JWT status/revocation mechanism would fall easily
>> within the remit of the WG as is.
>>
>>
>> I agree with this.
>>
>>
>>
>>
>> It seems to me as though the prospect of the formation of a new WG from
>> the potential SPICE BoF that may or may not be a suitable future forum for
>> the status list work has unintentionally delayed or diverted
>> attention around consideration of the status list work being adopted and
>> progressed in OAuth in the more near term.
>>
>>
>>
>>
>> Speaking as a contributor to SPICE BoF, this was certainly never my
>> intention.
>>
>> I don't think work should be delayed if it is well solved within an
>> existing working group, and I agree that status lists are relevant to JWT
>> and CWT generally, not just credentials.
>>
>>
>>
>>
>> [*] it has some open TODOs for CWT based representations but no actual
>> content as such, which could be removed to focus the scope of the draft.
>>
>>
>>
>>
>> +1
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 19, 2023 at 1:56 PM Orie Steele 
>> wrote:
>>
>> Excellent.
>>
>> Inline:
>>
>>
>>
>> On Tue, Sep 19, 2023 at 2:12 PM  wrote:
>>
>> Hi Orie,
>>
>>
>>
>> best regards,
>>
>> Torsten.
>>
>> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele <
>> orie@transmute.industries>:
>>
>> Torsten,
>>
>> Thanks for sharing this excellent framing.
>>
>> I agree with everything you said.
>>
>> Please correct me if I'm wrong about anything in this summary:
>>
>> 1. Keep working on JWT based credential formats at OAuth (implicit, don't
>> expand OAuth charter to work on CWT credential formats ?)
>>
>> yes
>>
>> 2. If a new working group (SPICE) is formed focused on credentials,
>> authors are open moving credential specific work items there, and don't
>> plan new credential related items at OAuth.
>>
>> We are open to move the credential work to a new working group. We are
>> open to discuss whether that will be SPICE, so far it seems to be COSE
>> centric. It’s clearly in everyone’s interest to have the JSON and COSE
>> based credential formats aligned.
>>
>>
>> I agree, I think a big part of this comes from trying to respect the work
>> that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and
>> OIDF.
>>
>>
>> 

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

[Giuseppe De Marco]

Hi,

I'm fashinated by these interpretation processes. It sounds resonable
having mapped the OAuth roles in three types:

Issuer or AS
Holder or Client
Verifier or RP

even if we try to keep things simple the real world continuosly breaks the
plans (as in the society the genders ...).

We often forget the User, that sometimes assumes the role of the "resource
owner"; and not at least the TTP, the trusted third party, whatever it
express in our minds, since trust still seems an abstract, or
controversial,  strategy, more sociological than ... Look, It Is everywhere
but still on the edge of the OAuth literature!

Anyway the challenge doesn't stop here, since in the Wallet ecosystem the
roles ends with swapping and mixing up, depending by the context, eg:

The holder became an AS during the presentation phase.

As in the biological, economics and sociological sciences, the diversity is
still the most important feature that allows a system to evolve, I believe
that the OAuth2 ecosystem with its solid roots Is the best place where this
diversity can be welcome. This Is also for the future of OAuth2 I believe.

I agree all the concerns about how the things are getting inflated and the
entropy increased losing the quality: everybody knows.

There might be the plan, or the vision, to merge some drafts together to
give the baseline for a complete architecture with well defined and
harmonized roles and features?

Il sab 9 set 2023, 15:44 Denis  ha scritto:

> 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 

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

[Giuseppe De Marco]

Hi,
I support the adoption.

Il mer 23 ago 2023, 21:02 Rifaat Shekh-Yusef  ha
scritto:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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] Call for adoption -

[Giuseppe De Marco]

I support Attestation-Based Client Authentication

Il sab 29 lug 2023, 22:17 Brian Campbell  ha scritto:

> I am in favor of adoption.
>
> On Sat, Jul 29, 2023, 1:27 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> This is an official call for adoption for the *Attestation-Based Client
>> Authentication *draft discussed in SF.
>>
>> https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *August 11th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials

[Giuseppe De Marco]

I support SD-JWT-based Verifiable Credentials

Il sab 29 lug 2023, 22:16 Brian Campbell  ha scritto:

> +1
>
> On Sat, Jul 29, 2023, 1:37 PM Michael Prorock  wrote:
>
>> I support adoption - but would request that if a group dedicated to
>> verifiable credentials is created prior to this draft being finalized, that
>> the group consider moving this draft to that group.
>>
>> Mike Prorock
>> CTO - mesur.io
>>
>> On Sat, Jul 29, 2023, 12:26 Rifaat Shekh-Yusef 
>> wrote:
>>
>>> All,
>>>
>>> This is an official call for adoption for the *SD-JWT-based Verifiable
>>> Credentials *draft discussed in SF.
>>> https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/
>>>
>>> Please, reply on the mailing list and let us know if you are in favor of
>>> adopting this draft as WG document, by *August 11th*.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> 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
>>
>
> *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
> 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 Protected Resource Metadata now with WWW-Authenticate

[Giuseppe De Marco]

Hi,
I am happy that this draft is progressing, draft 01 was adopted two years
ago for the Italian Attribute Authorities (SPID Attribute Authorities)
because there was a need to publish the metadata of a RS.
I see that many steps forward have been made and in a short time. I have
read Brian's reaction and believe it is important for the evolution of the
specification, which I hereby support

Il giorno mar 11 lug 2023 alle ore 02:34 Michael Jones <
michael_b_jo...@hotmail.com> ha scritto:

> In collaboration with Aaron Parecki , the
> ability for OAuth 2.0 protected resource servers to return their resource
> identifiers via WWW-Authenticate has been added to the OAuth 2.0
> Protected Resource Metadata specification. This enables clients to
> dynamically learn about and use protected resources they may have no prior
> knowledge of, including learning what authorization servers can be used
> with them.
>
>
>
> This incorporates functionality originally incubated in
> draft-parecki-oauth-authorization-server-discovery-00
> .
> Aaron and I had been asked to merge the functionality of our two drafts
> during an OAuth working group session at IETF 116. We’re both happy with
> the result!
>
>
>
> The specification is available at:
>
> ·
> https://www.ietf.org/archive/id/draft-jones-oauth-resource-metadata-04.html
>
>
>
>-- Mike
>
>
>
> P.S.  This notice was also posted at https://self-issued.info/?p=2377 and
> was referenced from
> https://twitter.com/selfissued/status/1677471513023508481.
>
>
> ___
> 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 for Feedback on "SD-JWT VC" Draft Specification

[Giuseppe De Marco]

Hi,

I support sd-jwt-vc with the will to contribute to its evolution and use it
in the wallet solutions under development

Il ven 26 mag 2023, 16:57 Oliver Terbu  ha
scritto:

> Dear all,
>
> I hope this email finds you well. I am writing to introduce "SD-JWT-based
> Verifiable Credentials with JSON payloads” (SD-JWT VC):
>
> https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/
>
> This proposal builds upon the existing SD-JWT specification by the OAuth
> WG and aims to address certain gaps and provide specific guidance for
> utilizing SD-JWT in the context of Verifiable Credentials. For example,
> while SD-JWT defines how to implement selective disclosure in JWTs (an
> important building block in many Verifiable Credential use cases), it is
> not opinionated about the specific JWT Claim Sets in the payload to
> represent Verifiable Credentials and used with HB-JWT.
>
> As you may be aware, the SD-JWT specification has already been adopted by
> the OAuth WG and has gained significant traction within the industry.
> However, the SD-JWT specification does not provide explicit guidance on
> using SD-JWT for Verifiable Credentials.
>
> The eIDAS 2.0 Architecture Reference Framework (ARF) has expressed a keen
> interest in utilizing SD-JWT for Verifiable Credentials, and SD-JWT VC
> became one of the two core credential formats of the European Digital
> Wallet (EUDIW):
>
>
> https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework
>
> Verifiable Credentials play a crucial role in enhancing digital trust and
> enabling secure identity interactions in various domains. To ensure the
> seamless integration of SD-JWT into the eIDAS ARF and similar initiatives,
> it is essential to address the existing gaps in the SD-JWT specification
> specifically relevant to Verifiable Credentials.
>
> As a general-purpose format, SD-JWT itself is not the right place to
> define these kinds of guidelines. The SD-JWT VC draft proposes to fill
> these gaps by defining additional requirements, clarifying ambiguities, and
> providing concrete guidelines for utilizing SD-JWT in the context of
> Verifiable Credentials. Since SD-JWT VC and SD-JWT are closely related, we
> propose to develop this specification in the OAuth working group.
>
> Your support and endorsement of this proposal would significantly
> contribute to the advancement of Verifiable Credentials.
>
> If you have any questions or require additional information regarding the
> "SD-JWT VC" specification or its potential impact, please do not hesitate
> to reach out.
> I’m looking forward to your feedback!
>
> Oliver Terbu
>
> --
> Director of Identity Standards, Spruce Systems, Inc.
> oliver.te...@spruceid.com
> ___
> 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-WG] OAuth 2.0 Protected Resource Metadata

[Giuseppe De Marco]

Hello everybody,

I would like to bring to your attention this expired draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

I propose the take up this individual draft for its adoption as an official
internet draft.
The reason I ask this is that there are implementations of this draft born
with the need to have metadata for entities of type RS.

The implementation of which I am aware concerns the Italian "Attribute
Authorities" [0]. OpenID Federation draft also defines the metadata of the
oauth_resource type [1], taking up the elements defined in the draft in
question. Recently, an interesting reflection seems to have arisen also in
OpenID4VCI/OpenID4VP [2].

Thank you for your attention, I hope to read your valuable feedback soon,
best

[0] https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html
[1] https://openid.net/specs/openid-connect-federation-1_0.html#section-4.7
[2]
https://bitbucket.org/openid/connect/issues/1781/do-new-entity-types-required-for-oid4vp
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

[Giuseppe De Marco]

+1 for the adoption!

Il mar 15 nov 2022, 15:43 Rifaat Shekh-Yusef  ha
scritto:

> All,
>
> During the IETF meeting last week, there was a strong support for
> the adoption of the following document as a WG document:
> https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/
>
> This is to start a call for adoption for this document.
> Please, provide your feedback on the mailing list on whether you support
> the adoption of this document as a WG or not, by *Nov 29th*.
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> 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] DPoP - Impementations

[Giuseppe De Marco]

Hi Riifat,

In italy DPoP was adopted in the Attribute Authority Infrastructure, below
a quick overview with few details
https://docs.google.com/document/d/11KQPEs7sln7DbxLN7r7q3j2PymBSrYNlx5o-W3xHQsw/


the italian delegation in the EU eidas expert group has developed, with
several contributions of the OIDC community, a Credential Issuance flow
adopting DPoP. This work is under discussion with other member states and
it will be shared as soon as possible.

Anyway, I want to confirm here that DPoP is a very important security
device for the italian eID infrastructure,

best regards

Il giorno mer 10 ago 2022 alle ore 23:40 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> All,
>
> As part of the shepherd write-up for the *DPoP* document, we are looking
> for information about implementations of this draft.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
> Please, reply to this email on the mailing list with any
> implementations that you are aware of to support this document.
>
> Regards,
>  Rifaat & Hannes
> ___
> 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] Call for adoption - SD-JWT

[Giuseppe De Marco]

Hi Neil,

The problem of the linkability affects both sd-jwt (opaque values) and
traditional jwt (readable values).

Even if I present an mDL or an sd-jwt without disclosing any user attribute
in It, the linkability Is possible exploting the VC itself and its public
key, adopted as proof of possession of the vc. The public key won't change
in different vcs if the wallet has only a single  private Key to sign it's
issuance requests.

A salted/hashed value doesnt tell you anything about its content but Is
still linkable, because It won't change, It Will be presented and presented
again and due to this It is traceable and a user linkable over many
different RPs.

As we have the pairwised subject id in oidc, that changes in relations of
the audience, well, even with VCs we May enable the concept of ephemeral VC
(and ephemeral bounded public Key). A Citizen that doesnt want to be
tracked may ask for the issuance of a VC for each RP.

Without enabling the advanced crypto in our implementations, the
salted/hashed strategy seems like the only usable for selective disclosure
in several contexts, thus a good issuance strategy covers the privacy
requirements as well, so let's give a place for sd-jwt because we really
need It, otherwise we'll have a future painted in mDoc/CBOR and jwt would
not be considered as an usable data format. Dont let this happen!

Best



Il mer 3 ago 2022, 00:10 Neil Madden  ha scritto:

>
> On 2 Aug 2022, at 21:04, Mike Jones  wrote:
>
> 
>
> Neil, you wrote:
>
> "SD-JWT is not simpler. Anyway, I think I have learnt enough from this
> thread, we don’t have to keep arguing the same points. I think the claims
> of combinatorial explosion are somewhat exaggerated and I don’t see
> compelling evidence of a real world need for selective disclosure in OAuth,
> so I don’t support this draft."
>
>
>
> Speculatively issuing JWTs with combinations of claims because they might
> be used in the future might be a fine strawman proposal to score debating
> points but is hardly a practical engineering solution.
>
>
> Why would it be speculative?
>
>   Whereas SD-JWT meets the needs of JSON-based use cases for selective
> disclosure using the issuer/holder/verifier pattern, including those for
> ISO Mobile Driver's Licenses.
>
>
> As far as I can see mobile driving licenses are the *only* concrete use
> case that has been mentioned so far. Did I miss one?
>
> Given that the goal is to reproduce “the user experience of presenting
> credentials in-person”, let’s look at one. My driving license lists the
> following information:
>
> * a unique driver id (which itself encodes part of my name, dob, and a
> male/female bit)
> * full name
> * address
> * date and country of birth
> * license issuer, issued-at and expiry dates
> * the categories of vehicle I’m entitled to drive
>
> ISO mobile drivers’ licenses are supposed to be unlinkable so the driver
> ID is out. The expiry and issued-at probably shouldn’t be able to be
> selectively non-disclosed. So that only leaves 5 fields: full name,
> address, date of birth, country of birth, and categories of vehicle.
>
> So even if you issued a separate JWT for each field, that’s only 5 JWTs.
> Why is that not practical?
>
> — Neil
>
>
>
> That's why I support adoption.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Neil Madden
> *Sent:* Tuesday, August 2, 2022 2:16 AM
> *To:* Kristina Yasuda 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption - SD-JWT
>
>
>
>
>
> On 2 Aug 2022, at 03:20, Kristina Yasuda <
> Kristina.Yasuda=40microsoft@dmarc.ietf.org> wrote:
>
>
>
> I support adoption.
>
>
>
> To add some color.
>
>
>
> One of the use-cases is a flow where issuance of a user credential
> (collection of user claims) is decoupled from presentation (where both
> issuance and presentation of a user credential are done using extensions of
> OAuth flows). The goal of this decoupling is to avoid “issuer call home”,
> where the user can send a user credential directly to the RP, without RP
> needing to contact the Issuer directly.
>
>
>
> So what’s the plan for revocation in this scenario? Something like OCSP
> Stapling? Short-lived tokens? Either way, the client will need to go back
> to the issuer regularly.
>
>
>
> So the motivations are not limited to offline scenarios, but are
> applicable to the scenarios that want to recreate in the online
> environment, the user experience of presenting credentials in-person.
>
>
>
> I’m not sure why this would be a goal. Presenting credentials in person is
> subject to many constraints that just don’t apply in the digital world.
>
>
>
>
>
> Driver’s Licence just happens to be an example familiar to many, and there
> is no reason it cannot be a diploma, or an employee card, or a training
> certificate, etc. But it is worth highlighting that SD-JWT work becomes
> critical if we are to enable ISO-compliant mobile Driver Licences expressed
> in JSON to enable 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Giuseppe De Marco]

Hi David,

This issue was already raised.
Below the proposal for both draft and python code

https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124

Regarding the privacy I'd like to have a combined presentation format that
makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim value).
You find some open issues for joining in the discussion

Best

Il lun 1 ago 2022, 14:50 David Chadwick <
d.w.chadw...@verifiablecredentials.info> ha scritto:

> I would like to add a few further points.
>
> The age-over property is more complex than your example, because a driving
> license only contains the date of birth. The issuing authority decides
> which age-over properties to statically provide in the mDL and the ISO
> standard provides an algorithm of how the wallet should respond if the
> age-over being requested is not present in the mDL. So different mDLs may
> contain different age-over properties and respond differently to requests
> for age-over from two people of the same age.
>
> The ISO mDL selective disclosure is more privacy protecting than the
> proposed SD-JWT because it also blinds the property names as well as the
> values.
>
> The examples below do not say why the use cases cannot work if the wallet
> has a set of conventional JWTs containing different commonly requested
> subsets of claims, such as age or address or classes of vehicle one can
> drive.
>
> Kind regards
>
> David
> On 01/08/2022 13:24, Warren Parad wrote:
>
> This is done because network availability and privacy concerns may
>> separate the act of acquiring the SD-JWT of a license from the issuing
>> authority, and presenting it (such as days later during a traffic stop on a
>> mountain road).
>
>
> I think we keep pointing to "offline drivers license" as the only reason
> we have this draft. But we still haven't made clear why the "offline
> drivers license" actually needs this. I spent some real time thinking about
> and came up with two hypotheticals that helped me.
>
> *Hypothetical 1:*
> You are on a mountain road and a police officer pulls you over, it's late
> at night, you have no internet, and your driver license is 100% digital.
>
> The officer wants to know if you live in the area, or if you are from out
> of state. You don't want to tell the police officer your name, you click
> some magic buttons on your device, and a QR code pops up. This QR code
> contains only:
>
>- "id_token" with salted fields
>- selective disclosure for: *address city + state*
>
>
> The police officer's magic new special SD-JWT device tells them you have a
> valid driver's license and that you live in the area. The officer is either:
>
>- Okay with that
>- Asks for further disclosure, which you can agree to or risk being
>arrested and brought in for questioning.
>
>
> *Hypothetical 2:*
> You live in the US and going out to a bar. Bars in the US are infamous for
> carding people. You want to tell them that you are over 21, but don't want
> to tell them anything else. So you take out your digital wallet and show
> them a QR code that only contains:
>
>- "id_token" with salted fields
>- selective disclosure for: *over 21*
>
> The bouncer uses their magic new SD-JWT device to verify that information,
> and can either say:
>
>- That's sufficient, come on in
>- I don't believe that is yours, I need to see your picture (including
>details), your name as well as another form of identification.
>
>
> *Problem from 2:*
> The bouncer says, I need to know you have been vaccinated against covid in
> the last 6 months. Here's where things start to get challenging, did the
> issuer have this information available to create a claim that could be
> selectively disclosed?
>
> Do we need to maintain a registry of all the allowed claims, or are
> countries some how going to be on top of this?
>
> What happens when different countries have different "standard claims"?
>
>
> On Mon, Aug 1, 2022 at 1:29 PM David Chadwick <
> d.w.chadw...@verifiablecredentials.info> wrote:
>
>>
>> On 01/08/2022 11:55, Neil Madden wrote:
>>
>> I agree with many of these points that Jaimandeep Singh raises.
>>
>> It would be good to know exactly what the intended use-cases within OAuth
>> are. In particular, in OAuth it’s normally the case that the client is
>> relatively untrusted and a privacy goal is to avoid revealing
>> information/PII to the client unnecessarily. In SD-JWT it seems that this
>> is turned on its head somewhat and we trust the client (holder) with
>> everything and instead want to keep some information private from the
>> resource servers?
>>
>> I think there are also some questions about exactly which claims can be
>> selectively disclosed - e.g., it would be a very bad idea to allow security
>> constraints like “exp”, “aud” or “cnf” to be selectively (not) disclosed.
>> But the problem is that the set of security constraints is not fixed in any
>> way, and new ones may be added by future specs or 

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Giuseppe De Marco]

With its salted/hashed approach SD-JWT rapresents the solution that allows
the selective disclosure of the claim values in a JWT, it's a concrete
alternative to ISO 18013-5 (mDoc) and also proposes a very interesting
integration with JWT-VC (vc-data-model 1.1).

Considering that in eIDAS 2 we can't enable yet the algorithms of advanced
cryptography unless they became standards, a discussion paper in the eIDAS
expert group has been presented to explore the capabilities of SD-JWT in a
concrete use case.

I think that SD-JWT is much more than an alternative to mDoc, it gives us
more features and flexibility than the latter, it's a concrete general
purpose format with many ongoing evolutions and potential integrations and
that's why I want to say:

+1 for SD-JWT

Il giorno ven 29 lug 2022 alle ore 02:17 Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com> ha scritto:

> All,
>
> This is a call for adoption for the *SD-JWT* document
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
>
> Please, provide your feedback on the mailing list by *August 12th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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