[Openid-specs-ab] Spec Call Notes 11-Mar-21

[Kristina Yasuda]

Spec Call Notes 11-Mar-21


Nat Sakimura

Mike Jones

Filip Skokan

Adam Lemmon

George Fletcher

Joseph Heenan

Tim Cappalli

Brian Campbell

John Bradley

Tom Jones

Kristina Yasuda

  *   Agenda
     *   Browser Interactions special call report
     *   Claims aggregation draft update
     *   External organizations (no time)

  *   Browser Interactions special call
     *   Tim reported on the progress of WedID
        *   WebID draft by Google evolved: https://github.com/samuelgoto/WebID. Explicit roadmap section added. But the topic is not yet ready for a WG.
        *   Concern of deferral of any problem into a enterprise construct. How you determine it is an enterprise context is a hard unsolved issue. "Work profile" concept is promising, but concern of it becoming a bucket is acknowledged. Firm stance - not against MDM augmenting,  butnothing will be dependent on device management, and can not be a requirement for enterprise scenarios.
        *   Still in the phase of educating Google on various use-cases.
     *   How much changes RP will be required to make - new AS? support a new API? new JSON file?
        *   George: OIDC breaks with WebID - some constructs remain, but not an OIDC flow anymore. Top-level question - any desire how to do what they want to do while preserving existing identity flow
        *   Tim: that is added to a new roadmap section. What can we do to profile these flow is create allow lists for those flows. May be able to classify OIDC flows. Are you ok that for 2 years advertisers leverage identity flows to continue tracking?
        *   George: browsers could do without breaking the flow is what safari does - do you want to log in to this website? If RP can advertise, that "this is OIDC provider I support". Very few RP open to a random IdP already. Easy for the browser to determine an identity flow - pause issuer during redirect and ask "do you want to log in" - will kill all the advertisers who do not want to involve the users. Option to the user to remember the decision.
        *   Tim: The minute we ask RPs to make changes, Google will say "than ask RPs to use this new API (for WebID from Google)
        *   George: to make WebID work now, RPs have to implement a new AS that talks a new protocol. cannot do the code flow. Are we ok as Connect WG with that?
        *   Tim: us creating a band-aid solution does not seem right, if google solidifies this API and it becomes standardized in W3C for example.
        *   John: W3C standard does not necessarily mean adoption.
        *   George: being identity guy for RPs, RP change over IdP change is a preference
        *   Nat: Putting just one JSON file in RP is easier than a new AS.
        *   John: I can see that the danger, the RPS will add the file, which puts all the fork button networks, or in other evil tracking people like Google ad sets, into that file.
        *   Nat: why does it have to be calling API? Instead of putting RP metadata file at RP domain
        *   Tim: because that assumes RP supports all IdPs.
        *   Mike: we probably only get one shot to ask people to change things. Companies are thinking of multiple phases of changes, but that is chaos. Zero to one opportunities. Many RPs will not change much unless web providers change a lot.
        *   George: if RP only change once, WebID should be a smaller priority than decentralized. RP will change whenever necessary to keep the traffic. RPs will need logged in traffic in the best interest of revenue stream. Log in walls if not pay walls. Dealing with decentralized identity is a larger change that the change we are talking about here.
     *   Role of DIDs
        *   Tim: disagree. processing is different, but transmission of the identifier and assertion remains the same.
        *   George: no, dealing with a claim signed by a private key of a user is different from a confidential client. Concept is similar but the code is different. Code change for decentralized identifier is important.
        *   Brian: concurring with George in difficulties in making these changes. Decentralized may be similar concept but changes required are larger.
        *   Tim: we have to stop of thinking of DIDs as only for decentralized identity. Why not use a spec as a structured identifier instead of Google creating a new identifier type. It is not only an SSI concept
        *   George: not against DIDs being used more broadly. That is not going to stop RP from saying "I received your DID, now give me your email". You can potentially build on top of DIDs and add additional cool features, and Apple and Google using pairwise pseudonymous identifiers would be great.
     *   Involvement of other browsers
        *   Mike: potential browser API will only build an ecosystem as far as browsers build it - but Apple is hostile to participate. Unless Apple and Firefox in, we can't change the browser world - WebAuthn proved it.
        *   John: I would not count on Firefox implementing anything like WebID soon
        *   Tim: firefox is at least loosely engaged with google. Apple is not even talking
     *   Vision: long-term solution
        *   Tim: For special browser calls, smaller group of 4 people will come up with a more detailed agenda to have more structure. We have to ask - as OpenID, are we looking at sustaining things, or are we looking into a long-term solution like account chooser, etc?
        *   George: long-term view but recognize there will be implementation hurdles and make sure things do not break unpredictably.
        *   John: looking at consolidated flows has to be grappled with. Web payments API to prevent extra concents. How we combine Conect, Webauthn so that we have consolidated flows for the user is a high priority.
        *   George: how to make customer journey better? Not just about authentication, but all identity lifecycle including revocation. Next gen OIDC that works with the browsers.
        *   John: in a privacy preserving way that preserves user experience. Much more free to experiment - Google?
     *   Use-cases missing
        *   Nat: is there use-cases for WebID?
        *   George: not in Google repo, but in IETF repo initiated by George and Vittorio: https://github.com/IDBrowserUseCases/docs
        *   Nat: Use-case and privacy considerations are very important. (privacy considerations) should not be dictated by what Google believes is privacy preserving. For example, Floc is a terrible idea https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea
     *   Efforts to align UI/UX needed
        *   George: a lot to learn in terms of user experience from webauthn. Do the user understand what it is? Words, UX describing external authenticator is different per implementation…
        *   Tim: whole fact that UI continue being this hostile for over 20 years - will be the devil. In Wifi alliance, got to agree the providers to follow UI/UX guide. It is unacceptable for each platforms. UI/UX certifications? Even chrome is not internally consistent.
        *   George: Is there a place for foundation to have a stronger voice in UX. Sub working group? Whatever we do at the protocol level should be a straight progression of where we want people to be.
        *   Tim: FIDO has a UI/UX working group that seems to work quite well.
        *   Nat/John: If output is some sort of the document that people are expected to follow, IPR agreement should be present

  *   Claims aggregation draft update
     *   Adam: not much to report on. Flows (in Credential Provider draft) are getting positive reviews as it sits today. Adam will send send the text version of Credential provider draft to the ML, and will start raising issues against claims aggregation draft.

  *    Quotes of the day
     *   "I received your DID, now give me your email"
     *   UI/UX certifiaction needed

Full notes are in the Wiki<https://bitbucket.org/openid/connect/wiki/Connect%20Meeting%20Notes%202021-03-11%20Atlantic>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210312/4cb2ae0b/attachment.html>