[Openid-specs-ab] Spec Call Notes 13-May-24
Tom Jones
thomasclinganjones at gmail.com
Tue May 14 20:29:44 UTC 2024
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/0663ced3/attachment-0001.html>
More information about the Openid-specs-ab
mailing list