[OAUTH-WG] Re: Call for adoption - First Party Apps

[Tim Cappalli]

IMO, we're getting very off topic here. The WebAuthn text is not part of
the draft being called for adoption.

On Thu, Sep 5, 2024 at 2:15 AM Neil Madden  wrote:

> On 5 Sep 2024, at 05:45, David Waite  wrote:
> >
> > 
> >
> >> On Sep 4, 2024, at 4:27 PM, Neil Madden 
> wrote:
> >>
> >>> On 4 Sep 2024, at 22:48, Watson Ladd  wrote:
> >>>
> >>> I can always grab the cookie jar off the user browser if I have that
> >>> level of access.
> >>
> >> USB access is not privileged, but that’s beside the point.
> >
> >>
> >> Put another way, the phishing-resistance of WebAuthn only really makes
> sense in a world of sandboxed apps: web apps, mobile apps. Any spec that
> encourages the use of OAuth auth flows outside of such sandboxed
> environments, as this one potentially does, is going to make defending
> against phishing harder.
> >
> > The client is not an identified/authenticated component in the
> architecture, so there is a user trust required in using a client - that
> the client actually is an agent acting in the user’s interest rather than
> acting maliciously.
> >
> > Platforms have the ability to provide specific API for these
> interactions to become a trustworthy client, and to block privileged access
> (including access to speak directly to hardware) behind audited
> entitlements to prevent from installed software acting as a malicious
> client.
>
> Right, this is what I mean by sandboxed.
>
> >
> > Note that some platforms also provide entitlements and heuristics for
> password manager access - however, as a knowledge-based system the platform
> cannot really prevent malicious applications from still attempting to
> manipulate their way to credential phishing.
> >
> >>
> >> (I’d also question why first-party apps need a standardised API for
> this anyway: they can do whatever they like using proprietary APIs already).
> >
> > I would struggle to come up with standards-track RFCs which would not be
> able to instead be accomplished with proprietary APIs. The editors and
> working groups found value in peer review and in interoperability.
>
> Standards are for promoting interoperability, not for getting free peer
> review of private APIs.
>
> >
> > I have seen the pitfalls of a proprietary approach to this and would say
> peer review is important. My primary concern is whether we can have a
> clients that authenticate against multiple implementing ASes based solely
> on this work. Profiling authentication methods like passkey-based
> authentication would go a long way toward alleviating that concern.
> >
> > -DW
>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

[Tim Cappalli]

Looks great! Some small proposed tweaks:

Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc.
No preference on which one is used, but should be consistent.

*6.2.3.1 *

Current text: "supports a new cross-device authentication protocol, called
"hybrid""
Proposed text: "supports a new cross-device transport protocol, called
"hybrid transports"

Propose adding the following at the end of the first paragraph: "CTAP 2.2
hybrid transports is implemented by the client and authenticator platforms."

Current text: "The main device and authenticator"
Proposed text: "The main device (CTAP client) and authenticator"

Current text: "The user will receive a push notification on the
authenticator."
Proposed text: "The user will typically receive a push notification on the
device serving as the FIDO authenticator."

*6.2.3.3*
Current text: "Both the Consumption Device and the authenticator require
BLE support."
Proposed text: "Both the Consumption Device and the authenticator require
BLE support and also need access to the internet"

s/hybrid transport/hybrid transports

Current text: "The mobile phone must support CTAP 2.2+ to be used as a
cross-device authenticator."
Proposed text: "The device serving as the FIDO authenticator must support
CTAP 2.2+ to be used as a cross-device authenticator."

tim

On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef 
wrote:

> *This message originated outside your organization.*
>
> --
>
> We have not received any feedback on this document so far.
>
> This is a reminder to review and provide feedback on this document.
> If you reviewed the document, and you do not have any comments or
> concerns, it would be great if you can send an email to the list indicating
> that.
>
> Regards,
>  Rifaat
>
>
>
> On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> This is a *WG Last Call* for the *Cross-Device Flows BCP *document.
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html
>> 
>>
>> Please, review this document and reply on the mailing list if you have
>> any comments or concerns, by *April 29th*.
>>
>> Regards,
>>   Rifaat & Hannes
>>
>> ___
> 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

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

[Tim Cappalli]

I support working group adoption of this draft.

tim

From: OAuth  on behalf of Rifaat Shekh-Yusef 

Date: Wednesday, April 27, 2022 at 09:50
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Step-up Authentication
This is a call for adoption for the Step-up Authentication document
https://datatracker.ietf.org/doc/draft-bertocci-oauth-step-up-authn-challenge/

Please, provide your feedback on the mailing list by May 10th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

[Tim Cappalli]

+1 in support of publication!



Tim Cappalli | @timcappalli<https://twitter.com/timcappalli>
did:ion:EiBgPHSLu66o1hQWT7ejtsV73PfrzeKphDXpgbLchRi32w

[Graphical user interface  Description automatically generated with medium 
confidence]


From: OAuth  on behalf of Rifaat Shekh-Yusef 

Date: Monday, February 21, 2022 at 08:13
To: oauth 
Subject: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document
All,

Mike and Kristina made the necessary changes to address all the great comments 
received during the initial WGLC.

This is a second WG Last Call for this document to make sure that the WG has a 
chance to review these changes:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C4fec1eb2c4154082d2c008d9f53bd5e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637810459918754372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QLrnO1Z%2BNsSrtb1tO6MYRh%2B6Eo%2BiXnHUz3lEC5TB4VE%3D&reserved=0>

Please, provide your feedback on the mailing list by March 7th.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Tim Cappalli]

I support publication of JWK Thumbprint URI specification.

Tim

From: OAuth  on behalf of Kristina Yasuda 

Date: Thursday, February 3, 2022 at 17:48
To: Vladimir Dzhuvinov , oauth@ietf.org 

Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
I support publication of JWK Thumbprint URI specification.
Kristina


From: OAuth  On Behalf Of Vladimir Dzhuvinov
Sent: Wednesday, February 2, 2022 7:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


+1 in support for a jkt URI RFC

Vladimir Dzhuvinov
On 02/02/2022 16:50, Mike Jones wrote:
Thanks Rifaat,

I support publication of the specification.

   -- Mike

From: OAuth  On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth 
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes






___

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

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

[Tim Cappalli]

I support adoption.

From: OAuth  on behalf of Rifaat Shekh-Yusef 

Sent: Thursday, January 13, 2022 09:26
To: oauth 
Subject: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

All,

This is a call for adoption for the JWK Thumbprint URI draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/

Please, provide your feedback on the mailing list by Jan 27th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Specifications for Identity Providers

[Tim Cappalli]

I think the first step would be finding the appropriate IETF group. I don't 
think this is in scope for OAuth-WG as this topic seems to be about account 
management and user credentials.

From: Kevat Shah 
Sent: Monday, August 9, 2021 16:14
To: mich...@palage.com 
Cc: Tim Cappalli ; oauth@ietf.org 
Subject: Re: [OAUTH-WG] Specifications for Identity Providers

How would that work? Would we need to work with W3C to ensure conformity of 
standards?

On Mon, Aug 9, 2021, 4:11 PM mailto:mich...@palage.com>> 
wrote:

Although the IETF has been involved in Best Commercial Practices (BCP) (see 
https://www.ietf.org/rfc/bcp-index.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfc%2Fbcp-index.txt&data=04%7C01%7CTim.Cappalli%40microsoft.com%7C41ce5aec4d7a4cf7efef08d95b726f93%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641369333693489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cDC15G1s1n4JCY%2Fk5vFDDyCj6WF%2Bhd8Pd4Fq0JNEIzQ%3D&reserved=0>
 )  which I think was the subject of Kevat’s original email.



So perhaps this is a subject matter that could co-exist in both the IETF and 
W3C?







From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Tim Cappalli
Sent: Monday, August 9, 2021 4:06 PM
To: kevats...@gmail.com<mailto:kevats...@gmail.com>
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Specifications for Identity Providers



I don't think there is explicit ownership, but generally password and magic 
link type "stuff" happens in W3C.



There are existing work efforts around standardizing password reset endpoint 
discovery, password complexity schemas, etc.



From: Kevat Shah mailto:kevats...@gmail.com>>
Sent: Monday, August 9, 2021 16:03
To: Tim Cappalli mailto:tim.cappa...@microsoft.com>>
Cc: oauth@ietf.org<mailto:oauth@ietf.org> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Specifications for Identity Providers



You don't often get email from kevats...@gmail.com<mailto:kevats...@gmail.com>. 
Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>

That's a good point. Is it fair to assume that W3C owns the standards for most 
(if not all) standards related to Identity Providers? Or does it make sense for 
IETF to start setting these standards in cases where W3C standards don't exist?



- Kevat

On Mon, Aug 9, 2021, 2:56 PM Tim Cappalli 
mailto:tim.cappa...@microsoft.com>> wrote:

I believe this topic would be more W3C scope, not IETF.



tim



From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Kevat Shah mailto:kevats...@gmail.com>>
Sent: Sunday, August 8, 2021 16:37
To: oauth@ietf.org<mailto:oauth@ietf.org> 
mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Specifications for Identity Providers



Some people who received this message don't often get email from 
kevats...@gmail.com<mailto:kevats...@gmail.com>. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>

I propose that we expand upon specific functionality provided by Identity 
Providers (IdPs) and tasks handled by them.



To start with, there should be clear specifications for various functionalities 
that IdPs provide such as:



- Email verification on registration

- Specifications regarding "forgot password" functionality

- Specifications regarding "resest password" functionality for users that are 
logged in





These specifications only pertain to Identity Providers, and allow an 
industry-wide set of rules that each Identity Provider must follow. The purpose 
of doing so would be to standardize various frequently used and implemented 
flows that are secure and widely reusable.







Some problems that would be addressed by these specifications would be:



- How to securely implement functionality where a user is sent a link to verify 
their email address



- How to securely implement functionality where a user is sent a verification 
code to verify their email address



- How to securely implement functionality where a user is sent a link to reset 
their password



- How to securely implement functionality where a user is sent a verification 
code to reset their password






___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Specifications for Identity Providers

[Tim Cappalli]

I don't think there is explicit ownership, but generally password and magic 
link type "stuff" happens in W3C.

There are existing work efforts around standardizing password reset endpoint 
discovery, password complexity schemas, etc.

From: Kevat Shah 
Sent: Monday, August 9, 2021 16:03
To: Tim Cappalli 
Cc: oauth@ietf.org 
Subject: Re: [OAUTH-WG] Specifications for Identity Providers

You don't often get email from kevats...@gmail.com. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>
That's a good point. Is it fair to assume that W3C owns the standards for most 
(if not all) standards related to Identity Providers? Or does it make sense for 
IETF to start setting these standards in cases where W3C standards don't exist?

- Kevat

On Mon, Aug 9, 2021, 2:56 PM Tim Cappalli 
mailto:tim.cappa...@microsoft.com>> wrote:
I believe this topic would be more W3C scope, not IETF.

tim

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Kevat Shah mailto:kevats...@gmail.com>>
Sent: Sunday, August 8, 2021 16:37
To: oauth@ietf.org<mailto:oauth@ietf.org> 
mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Specifications for Identity Providers

Some people who received this message don't often get email from 
kevats...@gmail.com<mailto:kevats...@gmail.com>. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>
I propose that we expand upon specific functionality provided by Identity 
Providers (IdPs) and tasks handled by them.

To start with, there should be clear specifications for various functionalities 
that IdPs provide such as:

- Email verification on registration
- Specifications regarding "forgot password" functionality
- Specifications regarding "resest password" functionality for users that are 
logged in


These specifications only pertain to Identity Providers, and allow an 
industry-wide set of rules that each Identity Provider must follow. The purpose 
of doing so would be to standardize various frequently used and implemented 
flows that are secure and widely reusable.



Some problems that would be addressed by these specifications would be:

- How to securely implement functionality where a user is sent a link to verify 
their email address

- How to securely implement functionality where a user is sent a verification 
code to verify their email address

- How to securely implement functionality where a user is sent a link to reset 
their password

- How to securely implement functionality where a user is sent a verification 
code to reset their password



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Specifications for Identity Providers

[Tim Cappalli]

I believe this topic would be more W3C scope, not IETF.

tim

From: OAuth  on behalf of Kevat Shah 

Sent: Sunday, August 8, 2021 16:37
To: oauth@ietf.org 
Subject: [OAUTH-WG] Specifications for Identity Providers

Some people who received this message don't often get email from 
kevats...@gmail.com. Learn why this is 
important
I propose that we expand upon specific functionality provided by Identity 
Providers (IdPs) and tasks handled by them.

To start with, there should be clear specifications for various functionalities 
that IdPs provide such as:

- Email verification on registration
- Specifications regarding "forgot password" functionality
- Specifications regarding "resest password" functionality for users that are 
logged in


These specifications only pertain to Identity Providers, and allow an 
industry-wide set of rules that each Identity Provider must follow. The purpose 
of doing so would be to standardize various frequently used and implemented 
flows that are secure and widely reusable.



Some problems that would be addressed by these specifications would be:

- How to securely implement functionality where a user is sent a link to verify 
their email address

- How to securely implement functionality where a user is sent a verification 
code to verify their email address

- How to securely implement functionality where a user is sent a link to reset 
their password

- How to securely implement functionality where a user is sent a verification 
code to reset their password



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

[Tim Cappalli]

Here’s the OSW recording on app2app.

https://www.youtube.com/watch?v=vktyY5CXwjg


From: OAuth 
Date: Tuesday, November 3, 2020 at 14:14
To: Joseph Heenan , George Fletcher 
Cc: oauth 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=26f11e54-06bb-45f0-ba83-5ff627ed5579]ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan 
mailto:jos...@authlete.com>> wrote:
Hi Dick

I didn’t attend the call so don’t know the background of this and the exact 
situation, but the general problem is mostly where the Authorization Server’s 
app is *not* installed. In that case Android falls back to much weaker 
mechanisms that allow other apps to get a look in. App links also aren’t 
consistently supported across all commonly used android browsers which causes 
further problems.

In general to do app2app oauth redirections securely on Android it’s necessary 
for both apps to fetch the /.well-known/assetlinks.json for the url they want 
to redirect to, and verify that the intent the app intends to launch to handle 
the url is signed using the expected certificate. Web2app flows are trickier, 
on both iOS and on Android. There were lengthy discussions on at least the 
Android case at OAuth Security Workshop this year (recordings available).

Joseph



On 20 Oct 2020, at 00:09, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links

An app is the default handler and the developer has verified ownership of the 
HTTPS URL. While a user can override the app being the default handler in the 
system settings -- I don't see how a malicious app can be the default setting.

What am I missing?

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=753a4eae-4c54-40f0-a603-09ea6cdfe434]ᐧ
___
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

Re: [OAUTH-WG] OAuth WG Interims - Aug/Sep 2020

[Tim Cappalli]

The original message (and calendar invite) said the 8/10 meeting was at 6am 
EDT. Is it 6 or 12?

tim

From: OAuth 
Date: Wednesday, July 15, 2020 at 18:05
To: oauth 
Subject: [OAUTH-WG] OAuth WG Interims - Aug/Sep 2020
All,

As you might have noticed, we are starting a series of interim meetings in 
August and September.
We have scheduled the following two meetings with specific topics:
1. Aug 3rd @ 12:00pm EDT to discuss OAuth 2.1 document.
2. Aug 10th @ 12:00pm EDT to discuss the PAR document

More to follow.

If you are interested in presenting your document during one of these upcoming 
interims, and have not contacted us already, please do so as soon as possible.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Example of financial aggregator authorization

[Tim Cappalli]

Hey all,

As mentioned on the call yesterday, here's an example of Capital One's 
financial data sharing flow for aggregators. Intuit's Mint is used in this 
example but others like Simplifi (Quicken) also use this flow. Chase and 
Capital One are the only two of my personal financial providers that provide 
delegated authorization vs screen scraping with direct user credentials.

Screencast of flow and Capital One-side screenshots:
https://1drv.ms/u/s!AkYnERHf4_toguJP2ZSDduOgkha9Zg?e=3GWW2d

Data sharing link presented during consent:
https://www.capitalone.com/legal/datasharing-terms-conditions

Hope this helps.
tim


 Tim Cappalli | @timcappalli<https://www.twitter.com/timcappalli>

[Microsoft logo]
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth