Re: [OAUTH-WG] OAuth Trust model

"auth providers" is an extremely confusing term. OAuth has no involvement in the content an RS provides the client -- the AS only provides authorization to access the content at the RS. It is common that the AS and RS are the same entity, but the protocol is designed to have a separation of

Re: [OAUTH-WG] [External Sender] Re: OAuth Trust model

Per https://openid.net/specs/openid-connect-core-1_0.html OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile

Re: [OAUTH-WG] WGLC for Browser-based Apps

Philippe: would you expand on your comment: On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck < phili...@pragmaticwebsecurity.com> wrote: - Remove unproven and overly complicated solutions (i.e., the service worker approach) A quick Google on oauth service workers returned a number of articles

Re: [OAUTH-WG] OAuth Trust model

e site to verify the identity. > > > Sorry for that stupid example but I'm really not able to explain the issue > in another way anymore :( > On 8/11/23 00:02, Dick Hardt wrote: > > This sentence does not make sense to me "which AS is AUTHORIZED at which > RS acti

Re: [OAUTH-WG] WGLC for Browser-based Apps

o having this as one of the > “recommended approaches” in an RFC. > > Hope this helps > > Philippe > > > On 11 Aug 2023, at 02:56, Dick Hardt wrote: > > > Philippe: would you expand on your comment: > > On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck < &

Re: [OAUTH-WG] [GNAP] Publication has been requested for draft-ietf-gnap-core-protocol-15

I just noticed this doc is up for publication. I did a quick search on the last call discussion, and did not see any +1s, nor any review by any of the active members of the OAuth WG. This is very surprising given the functional overlap with OAuth 2.0, and the years of deployment experience in

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

The NASCAR problem is rooted in the RP does not know which provider(s) the user has, so sites showed all the choices. FedCM only shows the provider(s) the user has. On Thu, May 9, 2024 at 5:33 AM Warren Parad wrote: > I think I'm still missing something, and I'm sure it was discussed >

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On Wed, May 8, 2024 at 4:07 PM Sam Goto wrote: > That's easier to answer: the browser needs name/email/picture to construct an > account chooser > , > which is the UX that tested best with users

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On Mon, May 13, 2024 at 5:15 PM Sam Goto wrote: > > > On Mon, May 13, 2024 at 4:50 PM Dick Hardt wrote: > >> >> >> On Mon, May 13, 2024 at 4:33 PM David Waite >> wrote: >> >>> >>> >>> > On May 13, 2024, at 4:10 PM, Dick

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On Mon, May 13, 2024 at 12:49 PM Sam Goto wrote: > > > On Sat, May 11, 2024 at 3:22 PM Dick Hardt wrote: > >> >> >> On Wed, May 8, 2024 at 4:07 PM Sam Goto >> wrote: >> >>> That's easier to answer: the browser needs name/email/pic

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On Mon, May 13, 2024 at 4:33 PM David Waite wrote: > > > > On May 13, 2024, at 4:10 PM, Dick Hardt wrote: > > > This seems in conflict with the Account Chooser that Google presents, > which users now understand as a way for them to select which Google account > th

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

github issues! > https://github.com/oauth-wg/oauth-v2-1/issues > > Aaron > > On Tue, May 14, 2024 at 5:14 PM wrote: > >> Internet-Draft draft-ietf-oauth-v2-1-11.txt is now available. It is a work >> item of the Web Authorization Protocol (OAUTH) WG of the IETF. >

[OAUTH-WG] DPoP introspection not including verification

Hey I was reading over RFC 9449 and was surprised that introspection did not take the DPoP header so that the introspection endpoint could do the check on the DPoP proof rather than forcing the Resource Server to do it.

Re: [OAUTH-WG] DPoP introspection not including verification

and > HTU values from the RS, as the AS would not know these directly. > > — Justin > > On Mar 10, 2024, at 4:05 PM, Dick Hardt wrote: > > Hey > > I was reading over RFC 9449 and was surprised that introspection did not > take the DPoP header so that the in

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Hope that makes sense. > > -Brock > > On 5/9/2024 12:04:13 PM, Dick Hardt wrote: > Would you elaborate on your point Brock? I don’t follow. > > On Thu, May 9, 2024 at 8:54 AM Brock Allen wrote: > >> This is why redirects with a custom UI are so essential. This allows >

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

ps a more complicated example than most, but this is exactly what > many organizations are doing today with OAuth and OIDC. > > Again, hope this makes sense. > > > -Brock > > On 5/9/2024 12:36:28 PM, Dick Hardt wrote: > Would that identifier first flow not just be par

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

ial to so many business use cases. > > > -Brock > > On 5/9/2024 11:06:23 AM, Dick Hardt wrote: > The NASCAR problem is rooted in the RP does not know which provider(s) the > user has, so sites showed all the choices. FedCM only shows the provider(s) > the user has. > >

[OAUTH-WG] Re: [ID-align] Re: Re: Re: Fwd: Internet Terminology Glossary

I had to look up "concordance" For drafts being worked on, it is a concordance. For finalized documents, it is a glossary. On Thu, Jun 13, 2024 at 2:26 PM Watson Ladd wrote: > On Thu, Jun 13, 2024 at 2:20 PM Dick Hardt wrote: > > > > > > > > On Thu,

[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary

ISO has its processes and IETF has its processes While useful to learn from other SDOs, we don't all need to work the same way. In the proposal, any WG can propose a new definition for an existing term, and refer to that definition. Collecting all the definitions is one of the goals. Is there a

[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary

On Thu, Jun 13, 2024 at 1:37 PM Denis wrote: > > The two following sentences seem to be contradictory: > > The glossary will contain: terms and definitions used in finalized > documents; and references to new terms and definitions being proposed in > draft documents. > > New definitions for

[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary

Living document is the right term. A key objective is that the glossary is a collection of definitions that were made in other documents. Terms can only be added to the glossary if they have an existing definition. This (hopefully) prevents the glossary work from becoming a bikeshedding

[OAUTH-WG] Re: [ID-align] Re: Re: Re: Fwd: Internet Terminology Glossary

( OAuth is in the cc cuz Rifaat :) The objective is to reduce confusion in standards development by gathering the definitions for terms used in existing specifications, and to create awareness of the existing definitions for new work so that existing definitions are used, or new definitions are

[OAUTH-WG] OAuth Client ID Metadata Document

Hey Aaron / Emelia I stumbled across https://www.ietf.org/id/draft-parecki-oauth-client-id-metadata-document-00.html (was any info posted to the list?) I like the general concept. Questions: 1. If an AS supports both registered, and unregistered clients, is there any guidance or requirements

[OAUTH-WG] Re: OAuth Client ID Metadata Document

On Mon, Jul 8, 2024 at 10:15 AM Emelia Smith wrote: > Just to follow up on this, further: > > > 1. If an AS supports both registered, and unregistered clients, is > there any guidance or requirements on differentiating between them such as > NOT issuing other identifiers that start with 'https"?

[OAUTH-WG] Re: OAuth Client ID Metadata Document

On Mon, Jul 8, 2024 at 11:33 AM Emelia S. wrote: > I would suggest that if an AS were to implement to competing > specifications for what a client_id means, then it'd be up to the > implementor to decide what is used when. E.g., it'd be difficult to support > both OpenID Federation and this I-D

[OAUTH-WG] Re: OAuth Client ID Metadata Document

Inline .. On Mon, Jul 8, 2024 at 9:06 AM Aaron Parecki wrote: > Thanks Dick, I hadn't gotten to post this to the list yet, but thanks for > kicking off the discussion! > > FYI there are already a few live implementations of this, and some > additional in-progress implementations. There is also

[OAUTH-WG] Re: OAuth Client ID Metadata Document

On Mon, Jul 8, 2024 at 12:38 PM Emelia Smith wrote: > > > On 8. Jul 2024, at 21:17, Dick Hardt wrote: > > > On Mon, Jul 8, 2024 at 11:33 AM Emelia S. wrote: > >> I would suggest that if an AS were to implement to competing >> specifications for what a

[OAUTH-WG] Re: We cannot trust Issuers

Richard, it all depends on how you scope the problem. Hellō uses garden variety crypto and does not have collusion issues and has true minimal disclosure as Hellō is an abstraction layer and the original issuer is not exposed. The internal operation of Hellō prevents any party from viewing user

<    1   2   3   4   5