Re: [OAUTH-WG] Redefining Confidential and Public Clients

2022-07-27 Thread Jim Willeke
Seems to be similar to the intentions of: https://datatracker.ietf.org/doc/html/rfc8176 and/or https://openid.net/specs/openid-connect-modrna-authentication-1_0-06.html -- -jim Jim Willeke On Wed, Jul 27, 2022 at 7:45 AM Jaimandeep Singh wrote: > Dear Aaron and esteemed members, > >

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

2021-02-24 Thread Jim Willeke
I didn't mean to imply "you" were writing it off and you are probably right technology may not be able to solve it, I was just looking for ways we might help? -- -jim Jim Willeke On Wed, Feb 24, 2021 at 10:21 AM Aaron Parecki wrote: > > Sure, you could write it off as &qu

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

2021-02-24 Thread Jim Willeke
oincide with the specifications might be in order. Just spend some time on https://stackexchange.com/filters/4229/oauth and you will see the issue and struggles. -- -jim Jim Willeke On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki wrote: > > You type your email address into {The Bat} to b

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

2020-07-16 Thread Jim Willeke
I support addoption -- -jim Jim Willeke On Thu, Jul 16, 2020 at 2:09 AM Dominick Baier wrote: > I support adoption > > ——— > Dominick Baier > > On 16. July 2020 at 01:54:08, William Denniss ( > wdenniss=40google@dmarc.ietf.org) wrote: > > I support adoption. &g

Re: [OAUTH-WG] Call for Adoption: DPoP

2020-03-17 Thread Jim Willeke
I support the adoption of DPoP. -- -jim Jim Willeke On Tue, Mar 17, 2020 at 8:21 AM Rifaat Shekh-Yusef wrote: > All, > > As per the conclusion of the PoP interim meeting, this is a call for > adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the > Applicat

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

2020-01-06 Thread Jim Willeke
I support adoption. -- -jim Jim Willeke On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt wrote: > I support adoption > ᐧ > > On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle 40amazon@dmarc.ietf.org> wrote: > >> I support adoption. >> >> >> >

Re: [OAUTH-WG] !@s in -security-topics-13

2019-12-24 Thread Jim Willeke
-- -jim Jim Willeke On Mon, Dec 23, 2019 at 5:56 PM Brian Campbell wrote: > There are a few occurrences of [!@RFC...] which presumably come from a > typo in the markdown source for mmark (switching the order of '@' and > '!'). > > *CONFIDENTIALITY NO

Re: [OAUTH-WG] MTLS and SAN

2019-04-05 Thread Jim Willeke
e (see, for example, [EV-CERTS])." And I believe this is the more common practice. https://security.stackexchange.com/questions/175786/is-it-required-to-have-the-same-domain-name-and-common-name-for-ssl-certificate/175788#175788 -- -jim Jim Willeke On Thu, Apr 4, 2019 at 4:55 PM Filip Skoka

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

2018-11-30 Thread Jim Willeke
+1 for the change. -- -jim Jim Willeke On Fri, Nov 30, 2018 at 5:36 PM Dick Hardt wrote: > + 1 to the change > > I'd suggest we work to define terms such as "sender constrained" in the > BCP so that it is clear what is meant by it. > > On Fri, Nov 3

Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob

2017-10-10 Thread Jim Willeke
Thanks for all the feedback. -- -jim Jim Willeke On Tue, Oct 10, 2017 at 11:02 AM, John Bradley wrote: > urn:ietf:wg:oauth:2.0:oob is a google thing that is not part of the OAuth > 2 specification. > > I think it was mostly a windows thing. > > It is not a real redirect U

[OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob

2017-10-10 Thread Jim Willeke
://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html - https://github.com/doorkeeper-gem/doorkeeper/issues/514 - https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html Should it be registered or defined? (or am I missing something?) With best regards, -- -jim Jim Willeke

Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices

2017-07-25 Thread Jim Willeke
+1 for adoption -- -jim Jim Willeke On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shekh-Yusef wrote: > All, > > We would like to get a confirmation on the mailing list for the adoption > of the *JSON Web Token Best Current Practices* as a WG document > https://datatracker.ietf.org/do

Re: [OAUTH-WG] New OAuth I-D: Incremental Auth

2017-07-10 Thread Jim Willeke
I know we add scopes based on the Authorization Server determining that the Resource Owner is also a "Paying Customer". (Well using OIDC so we KNOW they are a paying customer.) -- -jim Jim Willeke On Fri, Jul 7, 2017 at 9:03 PM, William Denniss wrote: > > On Fri, Jul 7, 2017 at

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

2017-02-02 Thread Jim Willeke
+! I agree this is needed. -- -jim Jim Willeke On Thu, Feb 2, 2017 at 4:33 PM, John Bradley wrote: > I am in favour of adoption. > > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig > wrote: > > > > Hi all, > > > > this is the call for adoption of

Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

2016-11-17 Thread Jim Willeke
o take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name. -- -jim Jim Willeke On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas wrote: > +1 to *It MAY be an absolute URI*, as specified by Section 4.3 of > [RFC3986]

Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Jim Willeke
Would a header be a concern if TLS was used for transportation? -- -jim Jim Willeke On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) wrote: > A header might open another attack vector. Better to parse the jwt and > look for the issuer assuming the jwt validates. > > Phil > &g

Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Jim Willeke
Why not register JWT as an access token type <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types> and then the the Issuer is implied? -- -jim Jim Willeke On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz wrote: > Kawasaki-san, > > This is a reall