1. Quick intros



          2. Discussion on purpose of SIOP special topic calls



          3. Discussion on the goals of new SIOP work

          a) Review requirements from requirements document: https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md

          b) Review discussions on scopes of work

          c) Process (e.g., tools, issues on bitbucket etc.)



          4. Overview of existing drafts and scopes addressed by each (in the order of introduction)

          a) OpenID Connect Claims Aggregation (adopted): https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md

          b) OpenID Self Issued Identifiers (adopted): https://bitbucket.org/openid/connect/src/master/SIOP/draft-jones-self_issued_identifier.md

          c) Self-Issued OpenID Provider V2, draft 01 (adopted): https://bitbucket.org/openid/connect/src/master/openid-connect-self-issued-v2-1_0.md

          d) OpenID Connect Credential Provider: https://mattrglobal.github.io/oidc-client-bound-assertions-spec/

          e) Smart Credentials: https://docs.google.com/document/d/1LuTuznSvmqveUKELNtV8eZOctcBgShND2e-Pemj5EYc/edit#heading=h.fsq33ckg25iw

          f) Portable Identifiers: WIP

          g) Anything missing?



          5. Next steps

          Kristina asked what people's goals are

          Tobias talked about self-issued OPs and credential exchange

          Mike said that we're adding new functionality for new use cases, while keeping existing things working

          Albert has been working on the DIF SIOP spec

                       He said that people already know and are using OpenID Connect

          John said that there may be work for hosted providers and potentially multi-tenant providers

          Tobias: The current SIOP chapter is designed for a particular deployment model

                       He'd like us to think about hosted providers and PWAs

          Oliver: Want to use SIOP for SSI and Credentials

          Tom: SIOP doesn't require the use of DIDs

                       It should work with traditional identities as well

                       John seconded Tom's remarks

          Tom said that there is also a draft talking about identifiers

          Tom talked about recovery - both lost key and lost account

          Markus mentioned https://github.com/decentralized-identity/secret-recovery-methods

          Kristina described the scopes of work covered by this specification

          Most importantly, it enables a level of indirection

          Mike said that the draft definitely does not do some things, such as portable identifiers, which could be in other drafts

          Adam asked about the use of https://self-issued.me/v2 as the issuer

          John said that self-issued.me shouldn't be used for discovery

          Kim said that PWA and web hosted wallets need ways to identify where the issuer is located

                       Kim said that you can tell that it's self-issued because there's a "sub_jwk" claim

          John said that the issuer has two purposes: discovery and the "iss" claim value

          Kim wants things to be as symmetrical as possible

                       Kim said that we need a strong discovery mechanism based on the OP's name

          Tobias is interested in portable identities

                       He wants them to work with any provider

                       Tom asked whether there is a flow that starts with the OP yet.  Tobias said no.

          Kim said that Tribe ID has all of this running and he could show us sometime

                       That includes discovery

          Mike said that self-issued.me is a logical identifier for your own identity provider

                       We're continuing to use it that way

                       That doesn't mean that other issuers couldn't also be used to locate providers on the Web

          Tobias said that the draft can be used to request Credentials

          Mike said that this could be used with either self-issued or standard OP and so probably does belong in its own specification

          Tom said that a credential service provider needn't be the same as an OP

                       John said that a CSP is more like what we call a Claims Provider

          Torsten said that a server that can provide Verified Claims could also be extended to provide Credentials

          Edmund said that it enables a SIOP to make a request to a Claims Provider to get Aggregated and Distributed Claims

          Adam said that it enables RPs to discover wallets and providers and communicate with them

          Kim said that Verifiable Credentials conform to particular Trust Frameworks

                       It happens in a privacy-friendly way

          Tobias, Torsten, Kristina, and Oliver are working on this

          No other drafts were mentioned

          We agreed on a bi-weekly schedule and use of Bitbucket issues