[Openid-specs-ab] Spec Call Notes 13-May-24
Aaron Parecki
aaron at parecki.com
Tue May 14 20:34:46 UTC 2024
If you have a microsoft account, tom at live.com, and the RP is using FedCM
against the Microsoft IdP login.microsoftonline.com, then the assumption is
that you have a cookie for login.microsoftonline.com for your tom at live.com
account. There is nothing special about the live.com email address being a
different domain. You can see this in action right now if you have a Google
account with a different email address domain, your non-gmail.com address
will appear in the FedCM popup when you visit an RP that uses the Google
IdP.
If you have accounts at foo.okta.com and bar.okta.com, they are entirely
independent, not part of a federation, and share nothing in common, so
there is no special behavior. If we're talking about a future version of
FedCM that works with arbitrary enterprise IdPs, the browser could say "I
need this user to sign in with an enterprise IdP", and if the user is
signed in to both foo and bar, both accounts would appear in the list, but
are entirely independent from each other.
On Tue, May 14, 2024 at 1:30 PM Tom Jones <thomasclinganjones at gmail.com>
wrote:
> I thought I was very specific. (Note that live.com IS NOT an IdP in the
> sense you mean, It just belongs to a federation that includes an IdP>)
> 1. What does the message from the verifier to the browser look like?
> Specifically, what labels does the list of known IdP (or should I say
> federations) contain?
> 2. How does that message get rendered by whatever browser the user has
> instantiated (assuming only that FedCM (and possibly a PM) is enabled by
> that browser)?
> -- I understand that the user state on that browser may impact the UX.
> Where "state" includes a variety of elements.
> I would be interested to know what the following might possibly mean
> (other than the user has logged into the browser's vendor site): registered
> it as an IdP in your browser
> Another thought. Suppose I have accounts at foo.okta.com and bar.okta.com,
> what is the federation identified to the browser by the verifier? (or is
> this out-of-scope?)
> Another question: Does the verifier have different requests for login
> versus registration? Or is the FedCM / PM expected to be able to
> disambiguate the request?
> ..tom
>
>
> On Tue, May 14, 2024 at 10:10 AM Aaron Parecki <aaron at parecki.com> wrote:
>
>> Are you talking about the "configURL: any" version or the RP providing
>> specific config URLs?
>>
>> In the "any" world, if you're logged in as tom at live.com, *and* if you
>> have visited the live.com IdP and registered it as an IdP in your
>> browser, then an RP that asks for "configURL: any" would get the
>> tom at live.com account in the FedCM dialog.
>>
>> I guess I don't understand the problem you're talking about.
>>
>> Aaron
>>
>>
>> On Tue, May 14, 2024 at 9:45 AM Tom Jones via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> I question the statement Aaron made - quoted below.. What would a logon
>>> request from an RP look like that could enable a meaningful UX? - consider
>>> login with MS as an RP option. If I am currently logged on as
>>> tom at live.com, how can (EVERY BROWSER that the user might have) connect
>>> that with MS logon?
>>>
>>> Aaron said that FedCM can help make things better by
>>> only showing identities that you have
>>>
>>> As opposed to showing all the IdPs that
>>> it is possible to use
>>>
>>> Research & Education sites have ornate
>>> IdP pickers among thousands of sites
>>>
>>> ..tom
>>>
>>>
>>> On Mon, May 13, 2024 at 5:35 PM Michael Jones via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> Spec Call Notes 13-May-24
>>>>
>>>>
>>>>
>>>> Mike Jones
>>>>
>>>> Sam Goto
>>>>
>>>> Aaron Parecki
>>>>
>>>> Tom Jones
>>>>
>>>> Dima Postnikov
>>>>
>>>>
>>>>
>>>> IdP Discovery Discussion
>>>>
>>>> We had a free-ranging discussion of IdP discovery
>>>> problems and solutions
>>>>
>>>> Also called Home Realm Discovery
>>>>
>>>> Motivated in part by problems that
>>>> FedCM is trying to solve
>>>>
>>>> Both closed sets are open sets of IdPs are used in
>>>> different contexts
>>>>
>>>> NASCAR screens are closed
>>>>
>>>> E-mail is an open space
>>>>
>>>> Federations are logically closed but
>>>> may have thousands of participants
>>>>
>>>> Different kinds of ecosystems have different properties
>>>>
>>>> Open Banking systems are closed
>>>>
>>>> Research & Academic Federations are
>>>> distinct from those
>>>>
>>>> SAAS apps are more open, accepting a
>>>> large set of corporate identities
>>>>
>>>> You may have identities from one
>>>> ecosystem that can't be used in another
>>>>
>>>> We discussed how blog commenting was the use case for
>>>> OpenID 2.0
>>>>
>>>> Which was an open system
>>>>
>>>> Having claimed identifiers
>>>> authenticated you and differentiated you from comment spam
>>>>
>>>> Bloggers knew they had URLs and were
>>>> willing to type them
>>>>
>>>> Whereas NASCAR screens have better conversion rates
>>>> than any UX where you have to type
>>>>
>>>> We talked about the need for incentives for ecosystem
>>>> participants
>>>>
>>>> Particularly for RPs
>>>>
>>>> Tom asked about user identifiers and picking IdPs
>>>>
>>>> Aaron said that FedCM can help make things better by
>>>> only showing identities that you have
>>>>
>>>> As opposed to showing all the IdPs that
>>>> it is possible to use
>>>>
>>>> Research & Education sites have ornate
>>>> IdP pickers among thousands of sites
>>>>
>>>> Mike said that one IdP discovery problem is people not
>>>> remembering which IdP they used at an RP
>>>>
>>>> Aaron remarked on the prevalence of e-mail as an
>>>> account recovery path
>>>>
>>>> Sam asked about the role of single-user OPs, such as
>>>> self-issued.info
>>>>
>>>> And about the cases where an e-mail
>>>> domain is the same as the IdP's domain
>>>>
>>>>
>>>>
>>>> Pull Requests
>>>>
>>>> https://bitbucket.org/openid/connect/pull-requests/
>>>>
>>>> PR #736: [Federation] listing endpoint parameters
>>>> updated_since and updated_before
>>>>
>>>> Dima: In open banking, etc. regulator
>>>> controls who is in and out
>>>>
>>>> Closed ecosystems
>>>>
>>>> Mike: Filtering on updated times
>>>> requires superiors to track changes in subordinates
>>>>
>>>> Mike: What kinds of updates are you
>>>> interested in knowing about?
>>>>
>>>> Dima: Added, key and
>>>> metadata changes, disabled/deactivated
>>>>
>>>> PR #731: [Federation] the new
>>>> federation_subordinate_events_endpoint
>>>>
>>>> Mike asked Dima to also look at this
>>>> for ConnectID's use cases
>>>>
>>>>
>>>>
>>>> Next Call
>>>>
>>>> The next call is Thursday, May 16 at 7am Pacific Time
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240514/8ab6968d/attachment-0001.html>
More information about the Openid-specs-ab
mailing list