[OAUTH-WG] PKCE RFC 7636 and registered URLs

Hi, is this sentence in the introduction of RFC 7636 still true? “The Redirection Endpoint URI in this case typically uses a custom URI scheme.” I think mobile applications should be registered by the developer for their domain. If the developer

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

Sorry, for me an all-capitalized MAY is not a recommendation to use PKCE MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

Why not RECOMMEND PKCE for CSRF protection, instead of that "MAY"? And in some cases MUST (verb) PKCE? //Axel From: Justin Richer Date: Wednesday, 3. January 2024 at 19:53 To: Nennker, Axel Cc: mail=40danielfett...@dmarc.ietf.org , oauth@ietf.org Subject: Re: [OAUTH-WG] Shepherd Review of dra

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

The email discussion triggered me jumping into the discussion. Also, I am looking into this from a Camara PoV. https://github.com/camaraproject/IdentityAndConsentManagement Camara is about to define what is a MUST for authorization servers etc and we are taking FAPI and the OAuth2 security best pr

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

Hi Daniel, there is also this sentence in this section https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#name-authorization-code-grant in a paragraph on it own. "Authorization servers MUST support PKCE [RFC7636

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

Hi, sorry for being late in the game. I am not too happy with this section: "Clients that have ensured that the authorization server supports Proof Key for Code Exchange (PKCE, [RFC7636]

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

Hi, There is an extra “where” in this Terminology definition: "reverse domain name notation" A naming convention based on the domain name system, but where where the domain components are reversed, for example "app.example.com" becomes "com.example.app". https://tools.ietf.org/html/d

[OAUTH-WG] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05

Nat, Could you please add reasons on why the 512 in this sentence "The entire Request URI MUST NOT exceed 512 ASCII characters"? It is in this section https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05#section-4.2 I assume it is hard to justify exactly this number and given that, I

Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request

https://tools.ietf.org/html/rfc6749#section-4.1.1 Authorization Request is explicit too. Naming could be about the why or the what. JAR is in the what-is-is category. “Signed and Encrypted Authorization Request” would be more in the why category. I think JAR is not bad. -A From: OAuth [mailto:

Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request

"OAuth 2.0 OpenId-ification" From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Freitag, 9. Oktober 2015 03:43 To: 'oauth' Subject: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request Hi OAuthers: One of the to do for https://tools.ietf.org/html/draft-ietf-oa

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

Hi, I think that draft-sakimura-oauth-tcse should reference http://tools.ietf.org/html/rfc6819 and especially reference the sections that this draft addresses. Regarding Prateek's comment about stateful servers: I think that a stateful server is the price the AS pays to ensure that the request

Re: [OAUTH-WG] JWS encoding Appendix A

Antonio, Please have a look at this https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104 The \r\n is the important. Please make sure you have this byte representation of the payload. The following octet sequence contains the UTF-8 representation of t

Re: [OAUTH-WG] IIW and OAuth

Same for me. Tues-Thurs works better for me too. Axel -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Monday, April 16, 2012 6:15 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] IIW and OAuth Can do, but

Re: [OAUTH-WG] Paper for the W3C Identity in the Browser Workshop aboutOAuth

Hi Hannes, A) Authentication Mechanisms Anders Rundgren is a caller in the desert for this for years: http://webpki.org/ B) Authorization Interface I think this is the point closest to oauth and that needs the most work. C) Standardized JavaScript Crypto Library Support This was discussed e.g. in

Re: [OAUTH-WG] JWT Implementation Question

I had all the java crypto routines (using Bouncycastle and lightcrypto libraries) in the xmldap library already and only needed to re-package. The jwt signature stuff is super simple. Although I use ASN.1 in the xmldap library too (to extract icons from X509 certificates) I think that ASN.1 is un

[OAUTH-WG] JSON Web Token Java implementation

My java code for implementing the new JSON Web Token draft-01 http://self-issued.info/docs/draft-jones-json-web-token-01.html is ready and commited to the openinfocard source code repository. JUNIT tests are here: https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x mldap/js

Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP

http://www.readwriteweb.com/cloud/2010/08/the-new-api-movement-may.php See #10 -Axel ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

That killer argument again. I allways tend to overestimate the skills of the developer. Thanks. -Axel -Original Message- From: David Recordon [mailto:record...@gmail.com] Sent: Tuesday, June 15, 2010 5:51 PM To: Nennker, Axel Cc: e...@hueniverse.com; oauth@ietf.org Subject: Re: [OAUTH-

[OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

During the meeting we had a (short) discussion about the expires_in parameter. I propose to change it to a notonorafter parameter with a GMT/UTC date as value. If the time slew between server is bigger or nearly equal to the life time of the expires_in value than the token receiver has no chance

Re: [OAUTH-WG] "3.4. Client Credentials" text change proposal

+1 -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Saturday, May 08, 2010 6:45 AM To: oauth Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal 3.4. Client Credentials When requesting access from the auth

Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

Two snippets from the emails below: > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. My comment on that comment: "opaque" for oauth could mean that oauth does not handle certain types of tokens specially. I think this is not an a

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

I challenge the claim that the spec gets harder to read. In fact the spec becomes cleaner if we move from one special case to a general description. Implementing other authn schemes while keeping the spec hardwired to shared-secrets might be trivial but those implementations will always be hacks.

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

But that gives us a flow for each type of client credential. I think it is better to talk about client_credentials and credential_type in flow that abstracts for credential types. -Axel -Original Message- From: David Recordon [mailto:record...@gmail.com] Sent: Wednesday, May 12, 2010 8:

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

I would rename "client_secret" to "client_credential" and "secret_type" to "credential_type". The client_credential might be a shared secret denoted by e.g. "credential_type=shared_secret". -Axel -Original Message- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, Ma

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

I suggest a change to "3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using a set of client credentials. The client credentials include a client identifier and an OPTIONAL symmetric shared secret. The means through which