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

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

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

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

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 -

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

ere 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 spoofing attacks. > > On Tu

[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

Re: [OAUTH-WG] Referencing TLS

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 le...@mnt.se wrote: 3 apr 2015 kl. 21:16 skrev John Bradley ve7...@ve7jtb.com: Yes it is good, though reading that BCP may scare off implementers who

Re: [OAUTH-WG] Referencing TLS

3 apr 2015 kl. 21:16 skrev John Bradley ve7...@ve7jtb.com: 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

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

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

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

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 to

[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

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/

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 WG

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/

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 sakim...@gmail.com: So that you know, Edmund Jay has implemented JWS including GCM for PHP. On Sat, May 26, 2012 at 8:10 AM, Mike Jones michael.jo...@microsoft.com wrote:

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 paul.mad...@gmail.com: Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose built code' - not

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

5 dec 2011 kl. 00:34 skrev Blaine Cook rom...@gmail.com: On 4 December 2011 02:26, Mike Jones michael.jo...@microsoft.com 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

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

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

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

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