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

Hi, I fully support the adoption best, G Il giorno gio 6 feb 2025 alle ore 17:37 Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> ha scritto: > All, > > This is a call for adoption for the *RFC7523bis* draft that was discussed > recently during the last interim meeting: > https://datatracker.ietf.o

[OAUTH-WG] Re: WGLC for Token Status List

Hi, I support adoption. Il giorno gio 2 gen 2025 alle ore 14:53 Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> ha scritto: > All, > > This is a WG Last Call for the *Token Status List *document. > https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ > > Please, review this document and

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

:04 Giuseppe De Marco ha scritto: > Hi, > > I used to support work made by other authors willing to find solution to > common problems. > I appreciate the efforts, the creativity and the passion I read within > those specs lines under the current approval phase. > > I

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

Hi, I used to support work made by other authors willing to find solution to common problems. I appreciate the efforts, the creativity and the passion I read within those specs lines under the current approval phase. I am happy about the link between PIKA and OpenID Federation, and that one of th

[OAUTH-WG] Re: Review of draft-ietf-oauth-selective-disclosure-jwt-10

Hi Mike, Regarding the definition of Holder, here I want to share an open issue that aims to clarify this kind of entity, even if it is opened for the openid4vc specs your revision reminds me it https://github.com/openid/OpenID4VP/issues/225 Il giorno lun 5 ago 2024 alle ore 05:55 Michael Jones

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

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 u

[OAUTH-WG] Re: Product Support for RFC8414 well-known URIs

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

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

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

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

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 librari

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

> 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

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

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 &

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

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

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

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 prot

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

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

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

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 tha

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

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

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

ng 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: > >> Cia

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

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 u

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

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 a

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

gt; 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 D

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

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 t

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

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

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

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

[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-v2-1-11.txt

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

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

d. 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_authorit

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

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

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

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

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

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.

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

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

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

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

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.

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

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 i

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

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

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

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 Author

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

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 requi

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

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 *

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

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 s

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

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 for

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

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 l

Re: [OAUTH-WG] Call for adoption -

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

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

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 bein

Re: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata now with WWW-Authenticate

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 reacti

Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification

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 JS

[OAUTH-WG] OAuth 2.0 Protected Resource Metadata

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

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

+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

Re: [OAUTH-WG] DPoP - Impementations

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 d

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

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 possess

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

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

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

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