Wiki

Justin Richer
David Waite
Tom Jones
Tim Cappalli
Tobias Looker
Vittorio Bertocci
Adam Lemmon
Edmund Jay
Jeremie Miller
Mike Jones
Balazs Nemeti
Pam Dingle
Kristina Yasuda
Regrets: Oliver Terbu

Discussion

Use-cases
- Kristina asked if a formal document with use-cases that require SIOP will be useful. It could be used as a guidance when making architectural decisions related to SIOP V2 draft.
- Mike agreed that this would be valuable. it is helpful to know in what kind of situations people are willing to use Self-Issued OP. Will be helpful with making choices with Verifiable/Verified Credentials for example.
- Vittorio also agreed with the need of such document. For example, the concept of an End-user controlling an identifier is not automatic in the spec reader's head.
- Tobias said that it may appear orthogonal, but the use-case document will also be helpful when clarifying the definition of Self-Issued OP and what changes and benefits it affords
- Tom said that he has a negative view on the use-cases when use-cases are created to justify what peole are building
- Mike stated that the fact that people are doing something means that they have a concrete reason to do it.
- Justin stated that We should focus on problems that people are interested in solving, not on solutions. That way use-case document is helpful in guiding technological discussions and directing towards consensus.

Following the discussion, Kristina started a SIOP Use-case document Wiki here: https://bitbucket.org/openid/connect/wiki/SIOP%20Use-cases Please contribute your use-case.

Issue #1212 Universal URL Based Discovery for SIOP
- Mike: Terminology matters. What is talked in this issue is not discovery and should be called choosing or selection.
- The group agreed to call this functionality Self-Issued OP Chooser.
- Tobias: To be more crisp, we are talking about three way negotiation btw RP, OpenID provider and end-user. What are we changing about the end user choice?
- Tom: there is nothing about standard in Self-Issued OP chooser. RP website can be made to be the link to the chooser
- Mike: We can do that now, but it is not happening. there is guidance for implementing user experience for choosing in OpenID Connect Discovery spec.
- Justin: There are two stages of IdP discovery, 1/ Figure out the issuer you have to go to; and 2/ How to deal with the issuer
- Jeremie (chat): the list in this issue is managed by a trust framework, not the user or relying party
Tobias encouraged the group to look for a generalized solution so that the account chooser would work for both Self-issued and conventional providers.
- Justin: the problem has always been to get RPs to trust any providers, does not matter if it is distributed or centralized. Either getting RP to do a general discovery like in this issue, or asking RP to put your button on their NASCAR screen.
- Mike: in the Academic Research and Federation world this is done all the time. In the Open ID Connect Federation spec, that's done via a hierarchy of trust statements by participants chaining up the roots of Trust. Such entity statements provide natural ways of establishing trust with providers that were unknown.
Vittorio: We are possibly stretching trust analogy too far. Usually RP chooses whom to trust. In this particular case, we implement user identity. Is trust still a right term? Does it make sense to talk about discovery?
- Tobias: Self-Issued OP's trust model becomes difficult to reconcile to OIDC, since conventionally provider identity is often important to RPs, and SIOP uses self-issued.me as iss and signed with the a key of an identifier that represents the user.
- Vittorio: There is a difference btw RP saying I will accept token from this provider vs I will accept self-issued tokens and acceptance such as validation of the token and user comes later. In SIOP, decision is made based on the particular content of the token, rather than the provenance of that token. (on the NASCAR screen) Does it make sense to put SIOP button next to the other IdP buttons from the traditional trust model?
- Pam (chat): are we talking about SIOPs and NLOPs, as two sub-classes of OP? (Where NLOP is "network-located" OP)
- David (chat): the ideas of claims aggregation and portable identifiers is to reduce the importance of the OP to that of a chosen and replaceable intermediary (to provide higher value authentication).
- David: traditionally, as a RP, you did not necessarily have an idea how to evaluate trustworthiness of either side - subject and OP. With SIOP, RP can evaluate the provenance of the data directly, and even if a business went under, you will be able to authenticate the user again, or do other means to recover their account access. In terms of reliability does not really matter as long as the user has access to the underlying Verifiable Credentials.
Vittorio: many differences: we just established it is not matter of trust - OP does not prove its identity what is important is the user. In SIOP, OPs are acting more as Attribute providers, not really as authentication providers. Does it have to be OpenID? Do we have to do SIOP or something else to manage VCs?
- Mike: there is no OIDC trust model. Whether to use a provider and which actions to take upon the claims received from the provider is entirely up to the RP. We can't change that
- Tobias: does not know if the current signing mechanism in SIOP is correct. keys used by the end-user are controlled by the provider.
- Justin: lost in philosophy of distributed identity, but ultimately it is about SW talking to SW
- Vittorio: key point - there is a difference btw SW that has its own identity and an identity on which we can base decisions. Provider that I trust and which user is not important vs when SW is just a tool and does not have its own identity. As a RP, there is a difference btw dealing with only one key and potentially tens of millions of keys
- ...this is not just about practicality like cost, but it is a matter of how these tools are used to model relationships. In theory should technically work because just signatures, but in practice there is a big difference in how people think about factoring their systems and the way system will perform in practice.
- ...in practice, if I have tools that works, and if they stop working, the concept of trust is not useful to solve the problem anymore.
- Justin: We are modeling a different kind of trust. trying to trust a fundamentally different kind of thing. Now cannot yet imagine seeing log in with SIOP under log in with Facebook, Google, etc.
- Jeremie agreed in chat that the conversation has been helpful to take next steps for another draft
Tom introduced Issue # 1215 SIOP requires user consent
Issue #1205 Indicating support for VCs (SIOP)
- DW gave update on the work to provide a means of supporting BBS+ and similar privacy-tooling signature types consistent with the JOSE stack. Draft coming.
- Related good discussion happening in W3C CCG Mailing list
From the chat:
- Tom: start of a trust model for us health care right now it only address trust in the app (aka wallet) https://trustregistry.org/