[Openid-specs-ab] SIOP Special Call Notes 02-March-21

Tobias Looker tobias.looker at mattr.global
Mon Mar 8 20:59:51 UTC 2021


Hi Tony,

Are you able to elaborate on this statement?

> ZKP work has been done with JWTs too

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker at mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Mon, Mar 8, 2021 at 6:52 PM Kristina Yasuda via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Notes are also here <https://bitbucket.org/openid/connect/wiki/2021-03-02>
> (Connect WG Bitbucket Wiki).
>
> Albert Solana
> Justin Richer
> Vittorio Bertocci
> Anthony Nadalin
> Tom Jones
> David Waite
> Oliver Terbu
> Tim Cappali
> Jeremie Miller
> Adam Lemmon
> Kaliya Young
> Edmund Jay
> Markus Sabadello
> Kristina Yasuda
>
>    -  IPR Agreement
>       - As the SIOP special calls are part the AB/Connect Working Group,
>       anyone wishing to participate and contribute need to submit a contribution
>       agreement: https://openid.net/intellectual-property/. The agreement
>       signed between DIF and OIDF doesn't extend to their member's IPR. I again
>       apologize for the confusion this question may have caused during the call.
>    - Update
>       - New WG in DIF "Wallet Security
>       <https://lists.identity.foundation/g/wallet-security>" is starting
>       (charter is being drafted) which discusses trust into the wallet is
>       in-scope. Tom said we should monitor the progress in that group to have
>       synergy and avoid overlapping scope with this group.
>    - Action items
>       - Write up a more concrete proposal on the discovery and present a
>       prototype at the next call (Jeremie and DW)
>       - Define success criteria for the discovery - number of SIOP SW
>       installed, etc. (Tom and Tim)
>
>
>    - New issues
>       - Value of iss = self-issued.me (#1208
>       <https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required>
>       )
>          - Questions: how to communicate the information about the SIOP
>          SW provider and what is the rationale to use self-issued.me
>          - What is the rationale behind using self-issued.me as `iss`
>          value?
>             - Oliver: it was used as a source of static OIDC
>             configuration because SIOP does not have a service endpoint. Questions why
>             self-issued.me is needed.
>             - DW: selfissued.me was not meant to be hit. Original
>             limitations of SIOP when it was created was that only way to invoke a
>             native app from a website was a custom url scheme. No good IPC channel
>             between them, so redirect was chose.
>             - Justin: goal of using this discovery launch point for SIOP
>             was that all device driven things are started the same way, without knowing
>             what kind of device you are trying to get to. Another hard issue is that
>             issuer identifier used throughout the protocol is based on the initial
>             discovery. In SIOP it pretends to be HTTP when it actually isn't.
>          - Oliver: any other requirement that RP needs to know discovery
>          endpoint upfront before the authorization request is sent?
>             - DW: You can't control what is kicked off using custom URL
>             scheme. Having individual URL for PWA that is universal link allows to use
>             specific wallet. That means users have to select which particular wallet
>             they want to use.  No control over what OS vendors would
>             reserve for authentication flows, and this is not a solvable problem,
>             rather tradeoffs.
>          - Tom: we could make a unified statement to the browsers what we
>          need - solving the NASCAR problem
>       - *Discovery proposal alternative to openid://*
>          - Jeremie: Best effort, not a perfect solution, leans heavily on
>          the platforms. Using the set of APIs that iOS, Android and Windows provide
>          to present the user with the selection from that is already installed
>             - Three parts. First, some common website to publish app IDs
>             as authorized apps to open links for a given path that all RPs will target
>             with a new Discovery request.
>             - Second, when user clicks that link, the platform will query
>             that website to discover if there is a local app that will handle the
>             request to that path, it will open app.
>             - Third, using the platforms' built-in share sheets
>             capability - OS will present a list of applications that can handle that
>             data. Any supporting app registered to receive that path would ask the OS
>             to present the list of application that can support handling that request.
>          - DW: analogy is a native app version of CHAPI. What we can do
>          now is self-issued.me can have metadata file for platforms that
>          says which issuer people can redirect to rather than openid://, native app
>          on the list will get triggered. Applications from third party app stores
>          would also be able to opt in to receive those requests. Share sheets also
>          work with app-to-app.
>       - Following discussion
>          - Tim: we need to define the success criteria. One or several
>          wallets.
>          - DW: agree. Is the user responsible for maintaining several
>             wallets that may conflict? Need to take into the reality of dependency on
>             the platforms.
>          - Oliver: Can return change the requirement `iss`=self-issued.me
>          if this new discovery mechanism is adapted? To include DIDs in `iss` for
>          example.
>             - Justin: Restrictions on the issuer identifier matching come
>             from the discovery specification in OIDC. if a new discovery mechanisms is
>             used, you're not bound to those same rules. It is fundamental to OIDC and
>             very deliberate that there are two different fields in OIDC - who is the
>             user and who says so.
>             - The two are tightly bound only in so much as a user account
>             is tightly bound to the IdP that asserts that user account. You do not want
>             to constrain self-issued identifiers by requiring somebody be identified by
>             their device because that is potentially very bad privacy risk, allowing
>             colluding RPs to share information about an individual user.
>             - DW: issuer and user identities today would have a parallel
>             to user and wallet iidentity attestations in the secure wallet space.
>             - Tom: wallet identifier and wallet instance identifier
>             should be distinguished.
>          - Supporting LD-proof signed claims
>          - Question addressed: how to send back VP signed by LD-proofs
>          - Oliver: proposal of introducing a new artifact vp_token that
>          would represent VCs signed using JWTs/LD-proofs. It would be wise to
>          support LD-proofs to embrace SSI community and allow new ZKP schemes (BBS+)
>          and other privacy preserving technology that DHS SVIP program actively
>          supports. Vp_token is a cleaner approach that is better from extensibility
>          (additional claims?). Question to the implementers if this is viable.
>          https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view
>             - Kristina:  introducing a new scope is a protocol change,
>             which has significant ramifications.  There would be lots of
>             questions to answer, like what triggers its addition (possibly use of a
>             "claims" request?), what if there are multiple VPs, etc.
>          - Tony: I would oppose is vp_token is exactly the same as VP,
>          because it may cause a problem processing. There is an issue of no approved
>          algorithms or canonicalization methods for LD-proofs. ZKP work has been
>          done with JWTs too.
>          - Tom: success of this spec should not be dependent on the
>          success of DIDs and VPs. You can canonicalize the whole VC/VP by putting it
>          into JOSE structure, expand the header section.
>          - Discussion on how much work RPs would have to do to accept
>          LD-proofs - add support for the existing relevant libraries or getting this
>          inside HSM to use for fundamental features.
>       - Call Schedule
>       - The next SIOP special topic call is in two weeks at the same time
>
>
>
> ------------------------------
> *差出人:* Kristina Yasuda <Kristina.Yasuda at microsoft.com>
> *送信日時:* 2021年2月4日 14:54
> *宛先:* openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
> *件名:* SIOP Special Call Notes 02-Feb-21
>
>
> SIOP Special Call Notes 02-Feb-21
>
> John Bradley
> Albert Solana
> Justin Richer
> Mike Varley
> Anthony Nadalin
> Torsten Lodderstedt
> Brian Campbell
> Tom Jones
> David Moeller
> Nader Helmy
> Oliver Terbu
> David Bantz
> Jeremie Miller
> Adam Lemmon
> Dion Bramley
> Kim Duffy
> Matt Randall
> Bjorn Hjelm
> Tobias Looker
> Edmund Jay
> Kristina Yasuda
>
> Regrets: Mike Jones
>
>
>
>    - Introductions
>
>
>    - Agenda Bashing
>       - Kristina: Today's agenda is to introduce "Portable Identifiers
>       work" and discuss scope and direction: driving use-cases, adoption
>       challenges, workstream name is a misnomer?, and relation to a MODERNA
>       account porting spec
>
>
>    - Overview of the Portable Identifiers draft
>    https://mattrglobal.github.io/oidc-portable-identities/ (WIP):
>       - Tobias: The problem addressed is how users can outlive the
>       Provider and be able to transfer identity from one provider to another and
>       what mechanisms are available to make this possible. Related work is an
>       account porting spec in OIDF MODERNA WG that defines mechanisms to
>       hand-over from one provider to another.
>       - *Mechanism we are exploring is using cryptography to establish
>       proof of control over the subject identifier *to allow transferring
>       ownership and consent of the user. DIDs establish a way to achieve this.
>       - SIOP, Chapter 7 in OIDC, allows for portability for co-located
>       model, this work tries to expand that to other deployment models
>
>
>    - Use-cases motivating the work
>       - Torsten:* SSI is about portability, but no one emphasizes it.*
>       Portable identifiers would provide a way for server cloud hosted wallets to
>       assert DIDs, which is impossible with the scope of SIOP V2 draft which
>       revises OIDC chapter 7 and is optimized for a deployment model where OP and
>       RP are co-located.
>       - Torsten: Example of *real life use-case would be British
>       Columbia's prototype* where a server-hosted OP uses DIDs and VCs.
>       Would als o like to enable banks in Yes.com ecosystem to assert
>       - Question from Kim regarding details of Section 6 "Subject
>       Identifiers"
>       - Tobias: in OIDC, identifiers are domain bound to the IdP's
>       namespace, but there could be other types of identifiers: jwk thumbprint is
>       one kind of identifier used in original SIOP section of OIDC and DIDs are
>       another kind.
>       - Kristina: *rough consensus in the WG since the beginning of SIOP
>       revision has been to introduce a layer of indirection to `sub` to allow it
>       to be a URI.* With this, DIDs can be used as subject identifiers.
>       - Clarification from Tony - "wallets" are not limited to mobile
>       wallets, any server hosted OPs would be able to assert DIDs.
>       - Tobias: "wallet" is an overarching term, used in particular
>       deployment models, but the function that it serves is OPs
>
>
>    - Why another attempt at portable identifiers will have a different
>    outcome (than i-names), whether for adoption by people, adoption by RPs, or
>    adoption by OPs?
>    - Tobias: Agrees with Mike's sentiment that normal people don’t care
>       about portable login identifiers.  This is more about identity
>       bound to the provider - trust relationship - does not want to offer
>       - John: with former i-names, problem was with a business model.
>       Given that larger providers give identifiers for free, paid IdP did not
>       fly. No one is against having portability, but no body was willing
>       to pay extra for it.
>       - Torsten: No one is willing to pay for identity - *the discussion
>       on business **model is related to the entire SSI-based model *and
>       should be separate from a technical discussion here.
>       - John: all comes down to the key management and asserting
>       identifiers, other things come along to be used. Currently, IdPs
>       use keys bound to their DNS which means using single key for all
>       identifiers. *There is a good reason to abstract that into being
>       able to use individual keys for individual accounts, separate from a
>       business model discussion.*
>       - Kim: we are focusing on a wrong use case. In educational
>       occupational credentials, *users **care about things remaining
>       usable over** life time, *and they don't care if it's phrased
>       portability. We just need to expand out to the use cases that
>       benefit from portability.
>
>
>    - Is "Portable Identifiers" is a misnomer?
>    - John: we are not talking about porting identifier themselves, rather
>       that* the **cryptographic keys used to prove control over
>       identifiers are portable* and can potentially be used to migrate
>       from one identifier to another.
>       - John: the naming can be "Portability of cryptographyc proofs to
>       assert control over identifiers" spec
>       - Kim: this is not about portable identifiers but portable
>       credentials associated with an identifier
>       - Tony: How do you define portable credentials?
>       - John: identifier is part of a credential, every credential is
>       essentially portable; need to define the language
>       - General consensus is yes. Alternative naming suggestions in a
>       chat: Portability between Identifiers rather than Portable Identifiers;
>       Inter-Identifier Portability (IIP)
>
>
>    - What changes would be required from OpenID Connect RPs to support
>    'portable identifiers'?
>    - As explored in the Portable Identifiers draft, RPs would have to expand
>       client metadata elements indicating support for supported subject
>       identifier types and did methods. *ID token would be fundamentally
>       signed by the provider who is performing the authentication, but there
>       would be a separate claim in the ID token that proves user's control over
>       the subject identifier.* Worst scenario - RP would assume
>       identifier is tied to the provider (instead of a user)
>
>
>    - What changes would be required from OpenID Connect OPs to support
>    'portable identifiers'?
>       - OP would need to support cryptographically verifiable subject
>       identifiers - including DIDs. And advertising support for those features
>       through OIDC discovery mechanisms
>
>
>    - No comments regarding the usage of VCs/VPs in OIDC
>
>
>    - Can this be a profile to MODERNA Account Porting spec?
>       - General consensus is no, *this should be a separate work due to a
>       differences in **concept and approach.*
>       - John: In MODERNA complete cryptographic proof is not used though
>       it was considered because you have an Old OP to provide look up services.
>       We should not be constrained by the choices MODERNA made.
>       - Bjorn: MODERNA porting is based on migration mechanism from
>       OpenID 2.0 to OpenID Connect. account porting spec is written in a very
>       flexible way
>       - Torsten: co-author of account porting spec - the spec assumes that
>       old OP is still operational even after account porting has happened.
>       Another big difference with Portable identifiers spec is the fact that in
>       account porting spec, identifier is always scoped in the name space
>       of IdP - not the case with DIDs.
>
>
> Minutes can also be found in Connect WG Bitbucket Wiki:
> https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20Call%20Notes%2002-Feb-21
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210309/bc4c1d2b/attachment.html>


More information about the Openid-specs-ab mailing list