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

[Warren Parad]

Some more evidence for this is most of our customers. We provide something
a bit different from Hello, but the ask is the same. The branding
experience for the widget must be fully controlled by the app developers,
this is the only way they'll support it. We have our own unified managed
login experience but most customers have designed a custom experience to
host inside their app.

Unless FedCM supports a purely API based flow, there is no way this is
going to get off the ground. Here, the authors of FedCM are so worried
about not allowing tracking, but while a problem, is not one that users
actually care about. They care about delivering their ticket at the top of
their backlog. That ticket doesn't say "make sure IDPs can't track our
users", it says "the login button must be blue".

In the future, no doubt there will be adoption in the long tail innovators
that don't care, but if we want actual usage by the early and late
majority, by actual companies and therefore provide value to actual users,
the UI must be fully controllable app side. So a full browser API for
handling user input and events for handling responses.

- Warren

On Tue, May 14, 2024, 02:35 Dick Hardt  wrote:

>
>
> 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 <
>>> da...@alkaline-solutions.com> 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
 they want to use. As a Google user, I find this experience with the Google
 IdP to work well. It would be confusing to me as a user if my name,
 picture, and email were not shown when selecting which Google account.  The
 "popup" like UX is nice on sites where I can use my Google account and
 provides a more seamless experience without a redirect, but I don't know of
 any other IdP that has deployed a similar UX.
 >
 > The challenge is that the "account chooser" is not how other IdPs
 interact with the user. For example with Hellō we let users have high
 fidelity on which name, email, picture they release with each RP, as
 studies[1] have shown that users will often pick a different combination of
 name / email / picture across sites that are crisply not aligned along
 personas captured in an account.

 The name, picture, and email are used for the picker displayed by the
 browser, based on IDP data for individual accounts. I do not believe these
 values are released to the RP (by the API) - the result of a successful
 interaction with the IDP for a selected user account is a credential object
 holding an IDP-provided string token. That token can contain or reference
 RP-specific attributes, such as pseudonyms.

>>>
>>> Did you look at the referenced issue?
>>> While the name/picture/email may not be released to the RP, it may not
>>> be clear to the user what will be released, particularly one that is not
>>> familiar with the Google Account Chooser.
>>>
>>
>> After the account chooser, IdPs can choose to use the Continuation API (
>> https://github.com/fedidcg/FedCM/issues/555), which allows them to open
>> a pop-up window to tell the user - using their own words in html/css/js -,
>> what's going to be shared with the RP.
>>
>> Would that help?
>>
>
> For Hellō, the popup would be a confusing UX as Hellō is an IdP
> aggregator, and a full redirect is a better experience on desktop as it is
> not just a release page as the user may select other IdPs / Issuers to
> gather additional data.
>
> I still think that we will get into an IdP permissioning model of some
> kind if the browsers are going to want to block link decorating redirects.
> A number of federation protocol features depend on 3P cookies -- and this
> is the most straightforward way to allow 3P cookies where they are needed,
> and pave a path to start blocking decorated redirects.
>
> IMHO browsers should manage permissions, not provide application level UX,
> which I consider login / registration to be.
>
> ___
> 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

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

[Dick Hardt]

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 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
>>> they want to use. As a Google user, I find this experience with the Google
>>> IdP to work well. It would be confusing to me as a user if my name,
>>> picture, and email were not shown when selecting which Google account.  The
>>> "popup" like UX is nice on sites where I can use my Google account and
>>> provides a more seamless experience without a redirect, but I don't know of
>>> any other IdP that has deployed a similar UX.
>>> >
>>> > The challenge is that the "account chooser" is not how other IdPs
>>> interact with the user. For example with Hellō we let users have high
>>> fidelity on which name, email, picture they release with each RP, as
>>> studies[1] have shown that users will often pick a different combination of
>>> name / email / picture across sites that are crisply not aligned along
>>> personas captured in an account.
>>>
>>> The name, picture, and email are used for the picker displayed by the
>>> browser, based on IDP data for individual accounts. I do not believe these
>>> values are released to the RP (by the API) - the result of a successful
>>> interaction with the IDP for a selected user account is a credential object
>>> holding an IDP-provided string token. That token can contain or reference
>>> RP-specific attributes, such as pseudonyms.
>>>
>>
>> Did you look at the referenced issue?
>> While the name/picture/email may not be released to the RP, it may not be
>> clear to the user what will be released, particularly one that is not
>> familiar with the Google Account Chooser.
>>
>
> After the account chooser, IdPs can choose to use the Continuation API (
> https://github.com/fedidcg/FedCM/issues/555), which allows them to open a
> pop-up window to tell the user - using their own words in html/css/js -,
> what's going to be shared with the RP.
>
> Would that help?
>

For Hellō, the popup would be a confusing UX as Hellō is an IdP
aggregator, and a full redirect is a better experience on desktop as it is
not just a release page as the user may select other IdPs / Issuers to
gather additional data.

I still think that we will get into an IdP permissioning model of some kind
if the browsers are going to want to block link decorating redirects. A
number of federation protocol features depend on 3P cookies -- and this is
the most straightforward way to allow 3P cookies where they are needed, and
pave a path to start blocking decorated redirects.

IMHO browsers should manage permissions, not provide application level UX,
which I consider login / registration to be.
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Sam Goto]

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 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
>> they want to use. As a Google user, I find this experience with the Google
>> IdP to work well. It would be confusing to me as a user if my name,
>> picture, and email were not shown when selecting which Google account.  The
>> "popup" like UX is nice on sites where I can use my Google account and
>> provides a more seamless experience without a redirect, but I don't know of
>> any other IdP that has deployed a similar UX.
>> >
>> > The challenge is that the "account chooser" is not how other IdPs
>> interact with the user. For example with Hellō we let users have high
>> fidelity on which name, email, picture they release with each RP, as
>> studies[1] have shown that users will often pick a different combination of
>> name / email / picture across sites that are crisply not aligned along
>> personas captured in an account.
>>
>> The name, picture, and email are used for the picker displayed by the
>> browser, based on IDP data for individual accounts. I do not believe these
>> values are released to the RP (by the API) - the result of a successful
>> interaction with the IDP for a selected user account is a credential object
>> holding an IDP-provided string token. That token can contain or reference
>> RP-specific attributes, such as pseudonyms.
>>
>
> Did you look at the referenced issue?
> While the name/picture/email may not be released to the RP, it may not be
> clear to the user what will be released, particularly one that is not
> familiar with the Google Account Chooser.
>

After the account chooser, IdPs can choose to use the Continuation API (
https://github.com/fedidcg/FedCM/issues/555), which allows them to open a
pop-up window to tell the user - using their own words in html/css/js -,
what's going to be shared with the RP.

Would that help?


>
>
>>
>> I imagine that use of the current API would have single entries for Hellō
>> accounts (if there happen to be multiple of them), and challenge for a site
>> like Hellō would be letting the user understand that the account selected
>> in the picker to initiate IDP interaction is not indicative of the
>> information being released to the RP. However, I think this is a general UX
>> issue for all IDPs using the federated credential API, unless they actually
>> plan to always release exactly the display attributes to the RP.
>>
>
> So far, I have no motivation to support the FedCM API. The experience in a
> browser redirect works fine.
>
>
>>
>> The /accounts endpoint I admit is the part of the current proposal I
>> understand the least. It seems like it mandates that the IDP know disparate
>> accounts which have some linkage across machines, such as different members
>> of a household.
>>
>> > In sharp contrast to the wallet UX / API that was demoed at IIW
>> recently, I find the browser is dictating too much of the UX in FedCM. It
>> enables an experience similar to what Google offers websites today where
>> login is enabled without a redirect -- but other IdPs don't provide that
>> experience -- which leads to the observation that this work is primarily
>> motivated to enable Google to continue offering its experience with the
>> demise of 3P cookies.
>>
>> I imagine the difference is that the system UX can delegate to native
>> applications in the passkeys and credentials case, and (on Android) can run
>> such applications in sandbox modes where they cannot save or report
>> metadata upstream over the network unless they are selected. FedCM is going
>> to need to delegate to web properties, and it can’t be expected that all
>> browsers will do heavy lifting to implement a particular sandboxing model
>> to protect from IDPs that might try to get a pipe into every website a user
>> visits that wants authentication. Likewise, platforms without Android’s
>> sandboxing model for applications likely will need a different approach for
>> credential wallets, and may require user consent for wallets to have access
>> to tracking information.
>>
>
> I thought the UX and API presented were from the browser, not the system.
>
> FWIW I find the passkey UX choices to be suboptimal. We only support
> WebAuthN on mobile platforms on Hellō for that reason, and use it primarily
> for convenience rather than security.
>
> Early in these discussions, we talked about the IdP prompting the user if
> it can be an IdP, and then getting access to additional functionality.
> Having a good UX around the permissioning would be a good area for the
> browser to iterate on the UX.
>
>
>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Dick Hardt]

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
> they want to use. As a Google user, I find this experience with the Google
> IdP to work well. It would be confusing to me as a user if my name,
> picture, and email were not shown when selecting which Google account.  The
> "popup" like UX is nice on sites where I can use my Google account and
> provides a more seamless experience without a redirect, but I don't know of
> any other IdP that has deployed a similar UX.
> >
> > The challenge is that the "account chooser" is not how other IdPs
> interact with the user. For example with Hellō we let users have high
> fidelity on which name, email, picture they release with each RP, as
> studies[1] have shown that users will often pick a different combination of
> name / email / picture across sites that are crisply not aligned along
> personas captured in an account.
>
> The name, picture, and email are used for the picker displayed by the
> browser, based on IDP data for individual accounts. I do not believe these
> values are released to the RP (by the API) - the result of a successful
> interaction with the IDP for a selected user account is a credential object
> holding an IDP-provided string token. That token can contain or reference
> RP-specific attributes, such as pseudonyms.
>

Did you look at the referenced issue?
While the name/picture/email may not be released to the RP, it may not be
clear to the user what will be released, particularly one that is not
familiar with the Google Account Chooser.


>
> I imagine that use of the current API would have single entries for Hellō
> accounts (if there happen to be multiple of them), and challenge for a site
> like Hellō would be letting the user understand that the account selected
> in the picker to initiate IDP interaction is not indicative of the
> information being released to the RP. However, I think this is a general UX
> issue for all IDPs using the federated credential API, unless they actually
> plan to always release exactly the display attributes to the RP.
>

So far, I have no motivation to support the FedCM API. The experience in a
browser redirect works fine.


>
> The /accounts endpoint I admit is the part of the current proposal I
> understand the least. It seems like it mandates that the IDP know disparate
> accounts which have some linkage across machines, such as different members
> of a household.
>
> > In sharp contrast to the wallet UX / API that was demoed at IIW
> recently, I find the browser is dictating too much of the UX in FedCM. It
> enables an experience similar to what Google offers websites today where
> login is enabled without a redirect -- but other IdPs don't provide that
> experience -- which leads to the observation that this work is primarily
> motivated to enable Google to continue offering its experience with the
> demise of 3P cookies.
>
> I imagine the difference is that the system UX can delegate to native
> applications in the passkeys and credentials case, and (on Android) can run
> such applications in sandbox modes where they cannot save or report
> metadata upstream over the network unless they are selected. FedCM is going
> to need to delegate to web properties, and it can’t be expected that all
> browsers will do heavy lifting to implement a particular sandboxing model
> to protect from IDPs that might try to get a pipe into every website a user
> visits that wants authentication. Likewise, platforms without Android’s
> sandboxing model for applications likely will need a different approach for
> credential wallets, and may require user consent for wallets to have access
> to tracking information.
>

I thought the UX and API presented were from the browser, not the system.

FWIW I find the passkey UX choices to be suboptimal. We only support
WebAuthN on mobile platforms on Hellō for that reason, and use it primarily
for convenience rather than security.

Early in these discussions, we talked about the IdP prompting the user if
it can be an IdP, and then getting access to additional functionality.
Having a good UX around the permissioning would be a good area for the
browser to iterate on the UX.
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[David Waite]

> 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 they 
> want to use. As a Google user, I find this experience with the Google IdP to 
> work well. It would be confusing to me as a user if my name, picture, and 
> email were not shown when selecting which Google account.  The "popup" like 
> UX is nice on sites where I can use my Google account and provides a more 
> seamless experience without a redirect, but I don't know of any other IdP 
> that has deployed a similar UX. 
> 
> The challenge is that the "account chooser" is not how other IdPs interact 
> with the user. For example with Hellō we let users have high fidelity on 
> which name, email, picture they release with each RP, as studies[1] have 
> shown that users will often pick a different combination of name / email / 
> picture across sites that are crisply not aligned along personas captured in 
> an account.

The name, picture, and email are used for the picker displayed by the browser, 
based on IDP data for individual accounts. I do not believe these values are 
released to the RP (by the API) - the result of a successful interaction with 
the IDP for a selected user account is a credential object holding an 
IDP-provided string token. That token can contain or reference RP-specific 
attributes, such as pseudonyms.

I imagine that use of the current API would have single entries for Hellō 
accounts (if there happen to be multiple of them), and challenge for a site 
like Hellō would be letting the user understand that the account selected in 
the picker to initiate IDP interaction is not indicative of the information 
being released to the RP. However, I think this is a general UX issue for all 
IDPs using the federated credential API, unless they actually plan to always 
release exactly the display attributes to the RP.

The /accounts endpoint I admit is the part of the current proposal I understand 
the least. It seems like it mandates that the IDP know disparate accounts which 
have some linkage across machines, such as different members of a household.

> In sharp contrast to the wallet UX / API that was demoed at IIW recently, I 
> find the browser is dictating too much of the UX in FedCM. It enables an 
> experience similar to what Google offers websites today where login is 
> enabled without a redirect -- but other IdPs don't provide that experience -- 
> which leads to the observation that this work is primarily motivated to 
> enable Google to continue offering its experience with the demise of 3P 
> cookies. 

I imagine the difference is that the system UX can delegate to native 
applications in the passkeys and credentials case, and (on Android) can run 
such applications in sandbox modes where they cannot save or report metadata 
upstream over the network unless they are selected. FedCM is going to need to 
delegate to web properties, and it can’t be expected that all browsers will do 
heavy lifting to implement a particular sandboxing model to protect from IDPs 
that might try to get a pipe into every website a user visits that wants 
authentication. Likewise, platforms without Android’s sandboxing model for 
applications likely will need a different approach for credential wallets, and 
may require user consent for wallets to have access to tracking information.

-DW
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Dick Hardt]

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/picture to
>>> construct an account chooser
>>> ,
>>> which is the UX that tested best with users by a far margin.
>>>
>>
>>
>> I bring up again the issue I filed
>> https://github.com/fedidcg/FedCM/issues/242
>>
>
> Yeah, that's a known issue. We actively are working on a subset of this
> problem here:
>
> https://github.com/fedidcg/FedCM/issues/559
>

I brought this up in response to

the *browser needs name/email/picture *to construct ...


I don't think the browser needs these


>> Registration and login are conflated in OIDC. showing the
>> name/email/picture implies those will be shared. That is commonly what
>> happens when using Google -- but other IdP's might have those attributes,
>> and it may not be what an RP needs, breaking the Law of Identity about
>> minimal disclosure.
>>
>> The FedCM architecture works well to solve the 3P cookie deprecation for
>> fancy Google login flow -- but standardizing that as how all login works
>> normalizes that email, name, and picture will always be shared -- not a
>> goal I think many of us are aligned on.
>>
>
> Yeah, no disagreement from my side that that's a non-goal, and not part of
> the end state. Purely sequencing strategy based on practicalities, from
> where I stand.
>
> As I said, I think the following will go a long way in making
> email/picture optional/unnecessary.
>
> https://github.com/fedidcg/FedCM/issues/559
>

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 they
want to use. As a Google user, I find this experience with the Google IdP
to work well. It would be confusing to me as a user if my name, picture,
and email were not shown when selecting which Google account.  The "popup"
like UX is nice on sites where I can use my Google account and provides a
more seamless experience without a redirect, but I don't know of any other
IdP that has deployed a similar UX.

The challenge is that the "account chooser" is not how other IdPs interact
with the user. For example with Hellō we let users have high fidelity on
which name, email, picture they release with each RP, as studies[1] have
shown that users will often pick a different combination of name / email /
picture across sites that are crisply not aligned along personas captured
in an account.

In sharp contrast to the wallet UX / API that was demoed at IIW recently, I
find the browser is dictating too much of the UX in FedCM. It enables an
experience similar to what Google offers websites today where login is
enabled without a redirect -- but other IdPs don't provide that experience
-- which leads to the observation that this work is primarily motivated to
enable Google to continue offering its experience with the demise of 3P
cookies.

Enabling a web app to discover which IdPs a user has, if the user has used
the IdP with the site, and if the IdP can provide the desired identity data
and then to allow the user to pick the IdP they want to use, and then let
the IdP own the UX (similar to the wallet UX demoed)

/Dick

[1] just kidding, I don't know of any official studies -- just my learning
from Sxipper, a form fill product I had, where we learned that people don't
really have precise personas they choose between for apps.
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Pieter Kasselman]

Thanks to Dean, Roy, Tim and Marco for the feedback in response to the working 
group last call for the cross-device security BCP. Your feedback helped to 
improve the draft, much appreciated.

All issues that were raised are addressed in the latest release which is 
available here: draft-ietf-oauth-cross-device-security-07 - Cross-Device Flows: 
Security Best Current 
Practice

With gratitude

Pieter


From: OAuth  On Behalf Of Pieter Kasselman
Sent: Thursday, April 25, 2024 8:43 PM
To: Tim Cappalli ; rifaat.s.ietf 

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

You don't often get email from 
pieter.kasselman=40microsoft@dmarc.ietf.org.
 Learn why this is important
Thanks Tim, really appreciating the feedback.

I opened two issues to track your feedback here:


  1.  Editorial updates for FIDO Section: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/138
  2.  Consistent use of Smart TV: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/137

Once again thanks for your feedback.

Cheers

Pieter

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Tim Cappalli
Sent: Wednesday, April 24, 2024 8:13 PM
To: rifaat.s.ietf mailto:rifaat.s.i...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

You don't often get email from 
tim.cappalli=40okta@dmarc.ietf.org.
 Learn why this is important
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 
mailto:rifaat.s.i...@gmail.com>> 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 
mailto: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
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-07.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-cross-device-security-07.txt is now available.
It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   Cross-Device Flows: Security Best Current Practice
   Authors: Pieter Kasselman
Daniel Fett
Filip Skokan
   Name:draft-ietf-oauth-cross-device-security-07.txt
   Pages:   55
   Dates:   2024-05-13

Abstract:

   This document describes threats against cross-device flows along with
   practical mitigations, protocol selection guidance, and a summary of
   formal analysis results identified as relevant to the security of
   cross-device flows.  It serves as a security guide to system
   designers, architects, product managers, security specialists, fraud
   analysts and engineers implementing cross-device flows.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-cross-device-security-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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

[Sam Goto]

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/picture to
>> construct an account chooser
>> ,
>> which is the UX that tested best with users by a far margin.
>>
>
>
> I bring up again the issue I filed
> https://github.com/fedidcg/FedCM/issues/242
>

Yeah, that's a known issue. We actively are working on a subset of this
problem here:

https://github.com/fedidcg/FedCM/issues/559


>
> Registration and login are conflated in OIDC. showing the
> name/email/picture implies those will be shared. That is commonly what
> happens when using Google -- but other IdP's might have those attributes,
> and it may not be what an RP needs, breaking the Law of Identity about
> minimal disclosure.
>
> The FedCM architecture works well to solve the 3P cookie deprecation for
> fancy Google login flow -- but standardizing that as how all login works
> normalizes that email, name, and picture will always be shared -- not a
> goal I think many of us are aligned on.
>

Yeah, no disagreement from my side that that's a non-goal, and not part of
the end state. Purely sequencing strategy based on practicalities, from
where I stand.

As I said, I think the following will go a long way in making email/picture
optional/unnecessary.

https://github.com/fedidcg/FedCM/issues/559
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Mahesh Jethanandani's No Objection on draft-ietf-oauth-security-topics-27: (with COMMENT)

[Daniel Fett]

Thanks for the review, Mahesh!

I fixed the usage of "man", "he", and "traditional" in this PR: 
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/99


The term "mastertheses" needs to remain as-is, as it appears only in a 
URL(!)


The term "native" is commonly used to describe a specific type of apps, 
see https://datatracker.ietf.org/doc/html/rfc8252, and I'd therefore 
like to keep it as-is


-Daniel

Am 12.05.24 um 07:31 schrieb Mahesh Jethanandani via Datatracker:

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-oauth-security-topics-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/



--
COMMENT:
--

Thank you for writing this document. Just a couple of comments.

Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "not RECOMMENDED"

The IANA review of this document seems to not have concluded yet.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language  for background and more
guidance:

  * Term "masterthesis"; alternatives might be "active", "central", "initiator",
"leader", "main", "orchestrator", "parent", "primary", "server"
  * Term "man"; alternatives might be "individual", "people", "person"
  * Term "he"; alternatives might be "they", "them", "their"
  * Term "traditional"; alternatives might be "classic", "classical", "common",
"conventional", "customary", "fixed", "habitual", "historic",
"long-established", "popular", "prescribed", "regular", "rooted",
"time-honored", "universal", "widely used", "widespread"
  * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
"intrinsic", "original"



___
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org