[OAUTH-WG] Re: We cannot trust Issuers

On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote: > I would observe that any solution based on garden-variety digital > signature (not something zero-knowledge like BBS / JWP) will have > problems with issuer/verifier collusion.  One-time tokens and batch > issuance don't help.  There is no

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

I think both Pauls and Giuseppes approches are needed and should progress in the IETF. Cheers Leif ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [SPICE] Relationship between SPICE and OAuth

I agree with Dick, Watson et al. To me moving some work around is a natural consequence of the identity area and the 3 party model growing in importance in the IETF and elsewhere. Given what’s happening in the EU and elsewhere this should not cone as a surprise to anyone.Cheers Leif3 nov. 2023 kl.

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

Second, how to do batch issuance of the credential (honestly, of any credential format: not just SD-JWT VCs but also mdocs and JWT-VCs) and whether it can be done low cost is out of scope of the credential format (or any of its components) specification itself. Btw when using OpenID4VCI (an

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

On 2023-08-24 02:02, Michael Prorock wrote: "Who exactly has an environment where any of the already existing pairing implementations, or a forthcoming BBS signature scheme wouldn't be available?" I have customers who are required to send regulatory trade data that may have redactions with FI

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

I support adoption too24 aug. 2023 kl. 08:31 skrev Vladimir Dzhuvinov : I support adoption. Vladimir Dzhuvinov On 23/08/2023 20:01, Rifaat Shekh-Yusef wrote: All, This is an official call for adoption for the

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

Perhaps you can write a draft describing your concerns. Suffice it to say that I don’t think you fully understand the requirements placed on the EUID wallet, nor the way the process to establish the EUID wallet works. For instance: anyone who claims to know what the EUID does or requires need

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

Support adoption > 29 juli 2023 kl. 12:28 skrev Rifaat Shekh-Yusef : > >  > 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

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

ConcurSkickat från min iPhone29 juli 2023 kl. 12:37 skrev Michael Prorock :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 ProrockCTO - mesur.ioOn

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

Likewise!Skickat från min iPhone27 maj 2023 kl. 01:12 skrev 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 developmentIl ven 26 mag 2023, 16:57 Oliver Terbu ha scritto:Dear all,I hope this

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

I support the adoption of draft-fett-oauth-selective-disclosure-jwt as a wg document On 2022-07-29 02:16, Rifaat Shekh-Yusef wrote: All, This is a call for adoption for the *SD-JWT* document https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/

Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs

might add something like this: There is an assumption that the client and server agree on the set of trust anchors the server uses to create and validate the certificate chain. Without this assumption the use of a SubjectDN to identify the client certificate would open the server up to certificate

[OAUTH-WG] cert spoofing in mtls & short-lived certs

So I reviewed the security considerations text which basically sais that the server can avoid being spoofed by managing its set of trust anchors. The text is better than nothing. However this lead me to ask another question about the use of SubjectDN as an identifier for the subject in client met

Re: [OAUTH-WG] Referencing TLS

urt and might just remind some people who > see stuff about DTLS and Cypher Suites in the BCP and have there brains turn > off. yeah maybe > > John B. > >> On Apr 3, 2015, at 5:08 PM, Leif Johansson wrote: >> >> >> >> >>> 3 apr 2

Re: [OAUTH-WG] Referencing TLS

> 3 apr 2015 kl. 21:16 skrev John Bradley : > > Yes it is good, though reading that BCP may scare off implementers who will > just ignore it. Those people are gona ignore a bunch of other good advise too. Lets not chase the rabbit down every hole. > > We may still want to give the current

Re: [OAUTH-WG] Fw: IPR Disclosure: - What to Do with JWT ?

On 02/28/2013 10:57 PM, Hannes Tschofenig wrote: > This is certainly a good point. Stating whether certain claims are > valid or not valid is not a good use of our time and may lead to legal > problems later on. > > So, read through the patents and make your own assessment whether this > IPRs are a

Re: [OAUTH-WG] Fw: IPR Disclosure: - What to Do with JWT ?

On 02/28/2013 08:21 PM, Oleg Gryb wrote: > Dear OAuth WG and Chairs, > > Can somebody please comment the Certicom's disclosure below? If the > purpose of this disclosure is to inform us that JWT can be potentially > a subject of royalties and other possible legal actions, the value of > adopting JW

[OAUTH-WG] review http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01

Some comments in the order I discovered them... - the term holder-of-_the_-key (my ascii-emphasis) is used when the normal terminology is just "holder-of-key", not sure what is added by the definite form... - s/incredients/ingredients/g - say "a mechanism for secure and scalable key management"

Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion

On 11/12/2012 10:09 PM, Phil Hunt wrote: > Leif, > > I've read this a couple of times and I think I'm getting lost in > partial SAML vs. OAuth terminology. As a result, I thought you were > saying: > > 1. It isn't practical to issue client credentials even with Dynamic > Registration > 2. You want

[OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion

I promised to send a UC to the list as input to the discussion around new token formats. --- Several large-scale deployments of public-key use a "bag-of-keys" model for key management: you stick endpoint information together with public keys for those endpoints in a signable container which is th

Re: [OAUTH-WG] Informal OAuth Chat @ IETF#84

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2012 10:43 PM, Phil Hunt wrote: > I can't do it before 5 Maybe find another day Hannes? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW814ACgkQ

Re: [OAUTH-WG] Informal OAuth Chat @ IETF#84

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2012 06:35 PM, Anthony Nadalin wrote: > You providing beer? > > -Original Message- From: oauth-boun...@ietf.org > [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Monday, July 30, 2012 9:33 AM To: oauth@ietf.org

Re: [OAUTH-WG] Informal OAuth Chat @ IETF#84

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2012 06:35 PM, Anthony Nadalin wrote: > You providing beer? > OAUTH provides enough buzz as it is -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYF

Re: [OAUTH-WG] [jose] Dominick Baier's JWT implementation

On that topic: what is the most current/complete implementation for python? 26 maj 2012 kl. 13:36 skrev Nat Sakimura : > So that you know, Edmund Jay has implemented JWS including GCM for PHP. > > On Sat, May 26, 2012 at 8:10 AM, Mike Jones > wrote: > FYI - Dominick Baier sent me a note let

Re: [OAUTH-WG] Mandatory-to-implement token type

Exactly 11 dec 2011 kl. 18:27 skrev William Mills : > They are only compatible in the sense that they share the same security > characteristics. > > From: Leif Johansson > To: Paul Madsen > Cc: "oauth@ietf.org" > Sent: Sunday, December 11, 2011 3

Re: [OAUTH-WG] Mandatory-to-implement token type

5 dec 2011 kl. 00:34 skrev Blaine Cook : > On 4 December 2011 02:26, Mike Jones wrote: >> I strongly object to a mandatory-to-implement clause for the MAC scheme. >> They are unnecessary and market forces have shown that implementers do not >> want or need this kind of an authentication sc

Re: [OAUTH-WG] Mandatory-to-implement token type

As an implementor of a toolkit let me offer this: the only use/requirement of mac that I've seen is for backwards compat with 1.0a. 4 dec 2011 kl. 14:15 skrev Paul Madsen : > Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose > built code' - not used to build OAuth cl

Re: [OAUTH-WG] Chairing change

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I'm sure you'll all join me in thanking Blaine for all his > excellent work in bringing oauth into and getting it (almost) > through the IETF process. Thanks Blaine! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using G

Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/15/2011 10:08 PM, Greg Brail wrote: > I understand and thanks for clarifying. I agree that there may be services > that do not want to support HTTP Basic at all for their authorization > flows and that requiring it would weaken the security of OA

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

Go implement whatever you want. But the spec should set the highest practical bar it can, and requiring HTTPS is trivial. As a practical note, if the WG reaches consensus to drop the MUST, I would ask the chairs to ask the security area and IESG to provide guidance whether they would approve su

Re: [OAUTH-WG] Scope using Realm idea

On 04/06/2010 11:50 PM, Eran Hammer-Lahav wrote: That's only when you need to trust the client. If your requirements demand registration, discovery is mostly pointless (other than dynamic configuration). At the risk of comparing apples and pears - many large-scale SAML deployments rely on di

Re: [OAUTH-WG] Draft progress update

On 04/02/2010 06:07 AM, Luke Shepard wrote: On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: If that's true, then how does the Authorization Server know what scope is appropriate at the Protected Resource? Does inclusion of the scope parameter require a 1:1 mapping between AS and PR, or at

Re: [OAUTH-WG] What are the OAuth design principles?

On 04/02/2010 01:57 AM, Peter Saint-Andre wrote: On 3/24/10 11:32 AM, Leif Johansson wrote: On 03/23/2010 12:00 AM, Eve Maler wrote: Since the discussion in the "OAuth after-party" seemed to warrant bringing it up, I mentioned the UMA design principles/requirements document. You c

Re: [OAUTH-WG] What are the OAuth design principles?

On 03/23/2010 12:00 AM, Eve Maler wrote: Since the discussion in the "OAuth after-party" seemed to warrant bringing it up, I mentioned the UMA design principles/requirements document. You can find it here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements The discussion is

Re: [OAUTH-WG] Signatures, Why?

On 03/04/2010 09:00 PM, Blaine Cook wrote: One of the things that's been a primary focus of both today's WG call and last week's call is what are the specific use cases for signatures? - Why are signatures needed? - What do signatures need to protect? Let's try to outline the use cases! Please