Re: [OAUTH-WG] JOSE/JWT Security Update Presentation

rg > https://www.ietf.org/mailman/listinfo/oauth > > -- Dave Tonge ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

> working group. > > Ciao > Hannes & Rifaat > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Dave Tonge CTO [image: Moneyhub Enterprise] <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubente

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

tificate as client credentials Or alternatively, a definition of "Mutual TLS" could be provided earlier on in the document. Thanks again for your work on this spec. Dave Tonge ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Client Registration in trusted federation

-medium term, so I'm also looking for solutions that do not use it. > I'm also not sure how the use of X509 certificates would fit in with an > RFC-compliant implementation of the Dynamic Client Registration Protocol. > > > > Thanks in advance for your help, > > Matt > > > > >

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Thanks James - definitely an interesting case. I'd be sorry to see ACME and other APIs go down the route of POSTing base64 encoded blobs for all API interactions. On Mon, 3 Sep 2018 at 14:56, Manger, James wrote: > ACME >

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Samuel, Thanks for the reply, I would definitely be interested in an updated draft. Both the signing spec and the canonicalization spec seem a lot simpler than JSON-LD. It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs Thanks Dave On Tue, 4 Sep 2018 at 23:33, Samuel

Re: [OAUTH-WG] Non-repudiation for API requests and responses

H Torsten I agree that use use of draft-erdtman-jose-cleartext-jws doesn't support non-repudiation for JSON HTTP requests or responses alone. There was a reference made earlier in the email chain to ACME which requires `url` to be added to the JWT payload, and mention was made that some header

[OAUTH-WG] Non-repudiation for API requests and responses

Hi all, I'm working with financial APIs - APIs to initiate payments and APIs to retrieve balances and transactions. May of these APIs are protected by OAuth 2.0 profiles, however there is a requirement to support the signing of API requests and responses for non-repudiation purposes. For

Re: [OAUTH-WG] Non-repudiation for API requests and responses

t worry we are headed back to RPC style SOAP like > containers based on JSON tokens that can be signed and that contain all the > semantics and data of a transaction to be signed. Now that I said that, > I’m going to go wash my mouth out. Ugh. > > Phil > > > > On Aug 31, 201

Re: [OAUTH-WG] OTP-flow use case (sharing energy data)

wrote: > Thanks Nov and Dave! > > I have several questions about CIBA. Is this mailing list the > appropriate place to ask them or is there another mailing list that is > for discussions about CIBA? > > Daniel Roesler > dan...@utilityapi.com > > > On Tue, Jan 15, 201

Re: [OAUTH-WG] OTP-flow use case (sharing energy data)

henticating) >> the user and determining the way in which the OTP code should be sent. If >> utilities are given some sort of non-secret user identification (e.g. >> address, phone number, account number, etc.), they should be able to send a >> user_code to the user tha

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01 > ). > > >> > > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. >

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks Vittorio for your presentation and putting this draft together. I agree with Dominck that there is a potential of things going wrong when `sub` has multiple meanings. However I can see that using `sub` for a client_id semantically makes sense in some situations and I agree that it makes it

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

s and differences. >>>>>>- I put together a presentation summarizing my findings and >>>>>>suggesting a rough interoperable profile (slides: >>>>>> >>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides

Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)

+1 for mtls_endpoints optional metadata Dave Tonge On Thu, 21 Feb 2019 at 00:09, John Bradley wrote: > I agree. > > If someone really wants separate meta-data nothing stops them from having > a separate AS with its own meta-data. > > John B. > On 2/20/2019 7:04 PM, Tors

[OAUTH-WG] Client assertions to endpoints other than the token endpoint

and profiles. Thanks Dave Tonge ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

Thanks Torsten for this article - it is incredibly helpful. I'm very much in favour of the "structured_scope" approach. While I understand George's point I think the line is very blurred between coarse-grained scopes and fine-grained transaction consent. In addition fine-grained authorisation

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

cryptographically >> strong pseudorandom algorithm >> >> >> I assume this includes the use of a random number inside of a JWT, in >> case the AS wants to use JWTs as the "request_uri" parameter"? If so, >> it's probably worth spelling that out a

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

point is that you can do this > kind of thing right now, so DPoP needs to have a stronger justification for > why this isn’t sufficient. > > > 2. Make the DPoP token be a simple JWT with an "iat" and the origin of the > RS. This stops the token being reused elsewhere but the

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

; > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > > > Aaron Parecki > > aaronparecki.com > > @aaronpk <http://twitter.com/aaronpk> > > &

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

t; immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > > *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 oth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

auth >>> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> >> | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no | >> ___ >> OAuth

Re: [OAUTH-WG] PAR - Can AS/client require request object?

Works for me also ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

>> 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] Issuers, Discovery Docs & Brands

nd OIDC Discovery) Option 3 is invalid and that leaves us with options 1 and 2. Option 1 can be problematic as often it is in reality the same `issuer` behind the scenes. We would like to get feedback on this issue and potentially an extension to RFC8414 to allow the definition of multiple authorizat

Re: [OAUTH-WG] WGLC Review of PAR

any PSD2-licensed client is asserted by an eIDAS >>> compliant CA in a special X.509 certificate. Those certificates contain the >>> permissions (access to account information and/or payment initiation >>> allowed) and the identity (member state specific). But they don’t c

Re: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack

Hi Guido We've also discussed this issue in the FAPI Working Group at the OpenID Foundation. We came to the conclusion that we should require the use of either RFC8414 or OpenID Connect Discovery. I'd be in favour of adding the recommendation to the BCP. I'm not aware of an attack in the wild

Re: [OAUTH-WG] Implementation questions around refresh token rotation

n only catches a subset of possible attacks. > > — Neil > > On 12 Oct 2020, at 05:43, Dave Tonge wrote: > > > Our goal is to prevent cases where we lose the ability to Refresh a > Token due to transient issues (which have run the gamut from network > problems to ba

Re: [OAUTH-WG] Implementation questions around refresh token rotation

RTs "R1.1" >> and "R1.2", what happens if "R1.2" is then later used? Would you invalidate >> "R1.1" at that point? If so, why, and if not, why not? >> >> >> >> It would be most interesting to hear practical experience from peo

Re: [OAUTH-WG] ECDH-1PU encryption algorithm

cases can be accommodated without significant changes, so I think the > OAuth WG would be a good venue for advancing this. > > I’d be interested to hear thoughts and discussion on the list prior to any > discussion at an interim meeting. > > — Neil > ______

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

trust clients to obtain consent we wouldn’t need OAuth at > all. > > I thought the same initially, but we must distinguish between legal > consent and strong authentication/transaction authorization in such a case. > Legal consent can be obtained in various ways including the traditional > OAuth user co

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

e that > the same user is involved in the subsequent authorization flow. > > There is precedent for step 2 - e.g., token introspection currently allows > an access token instead of client authentication. > > If RAR was then updated to discuss this issue in the security > considerations (or elsewhere) with a referen

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

l": >> > >>>>> "https://loadsamoney/business/logo.png; >> > >>>>> >> > >>>>>? ? ?}, >> > >>>>>? ? ?{ >> > >>>>>? ? ? ?"authorization_endpoint"

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

ng list by *July 29th.* > > Regards, > Rifaat & Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Dave Tonge CTO [image: Moneyhub Enterprise] <http://www.goog

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

h-resp/ > > Please, provide your feedback on the mailing list by Dec 22nd. > > Regards, > Rifaat & Hannes > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Dave Tonge CTO [imag

Re: [OAUTH-WG] PAR error for redirect URI?

closure 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.__

Re: [OAUTH-WG] WG Last Call on the RAR Document

have reviewed the document and have no > concerns would also be very helpful. > > Regards, > Rifaat & Hannes > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Dave Tonge CTO [image:

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: IPR Confirmation

r any purpose, or store or copy the >> information in any medium. Thank you. >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> __

Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

faat & Hannes > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > ht

Re: [OAUTH-WG] WGLC for DPoP Document

___ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- https://danielfett.de > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

> Something else we may want to provide is some clear recommendations on when to use CIBA vs Device Authorization Grant etc I think this would be really helpful. Both specs support "decoupled" flows, but they were designed for different use cases and have different trade-offs. CIBA provides a

Re: [OAUTH-WG] A proposal for a new Internet Draft

For something more fine-grained than scopes there is RAR: https://www.ietf.org/archive/id/draft-ietf-oauth-rar-23.html On Mon, 3 Apr 2023 at 18:19, Clinton Bunch wrote: > I was under the impression from my reading of the spec, that scopes were > only ever intended as coarse-grained