14B/ SIOP - progress on the laundry list (wrt DID)
SIOP: Progress on the Laundry List (wrt DID)
Wednesday 14B
Convener: Tobias Looker, Oliver Terbu, Kim Cameron, Kristina Yasuda
Notes-taker(s): Kristina Yasuda
Tags for the session - technology discussed/ideas considered:
Self-issued OpenID Provider, OpenID Connect, CHAPI, DIDAuthn, OIDF, DIF
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Agenda
What is SIOP/did-siop & WG in OIDF
SIOP requirements list
Laundry list update/deep-dive & from IdPs to IdSPs
PWAs and SIOP
Intro Slides: https://docs.google.com/presentation/d/1K9jlC17uDC-JYiomcJI8cbZX8pXJwJZcr5Y8M_9c1T0/edit?usp=sharing
SIOP is in session 7 of OIDC spec
No OP needed
Identifier represented as asymmetric key pair controlled by the user
Limitations: crypto, etc.
DID SIOP - spec version 0.1 in DIF (https://identity.foundation/did-siop/)
Id_token used to prove user control over a DID
Adds new claim to id_token
Challenges: incomplete for iOS and desktop
Work done in OIDF
Requirements List for SIOP: https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md
Laundry list update: https://docs.google.com/presentation/d/1mNkseYBxOs90whrgDonYyVZj3SqA2QGsn_pp-JpLapY/edit?usp=sharing
3 Problems SIOP attemps to solve
Portable identifiers between providers
Sub / sub_jwk claim
The NASCAR Problem
openid:// scheme
Dealing with different deployment types of OP
4. PWA and SIOP: https://drive.google.com/file/d/1LZHgcyaEm1CgtKucN0Gib4BvQ4m-_Cho/view?usp=sharing - From IdP to IdSP(Identity service provider)
- Currently, large providers give us identifiers; in a new model, user uses wallets to self-issue identifiers and manage their keys; to which claims providers issue claims
- ID key Service Provider?
Next Steps:
- Join OIDF WG calls!: https://openid.net/wg/connect/
- File issues in BitBucket: https://bitbucket.org/openid/connect/issues?status=new&status=open
Resources
- Orie: demo, using PWA, SIOP and CHAPI… https://chapi-siop.did.ai/
- a demo PWA wallet: https://wallet.interop.transmute.world/
Questions, Comments highlight
- Ben: can we use DID uri as redirect_uri?
- Have not thought of it..
- Adrian: does SIOP solves user-tracking problem? -> in theory, yes. Would depend on the implementation
- Debbie: Are identifiers portable in 2 directions?
- Adrian: overlap with FIDO 2
- Dmitri: proposal to alternative for a custom URL scheme? -> nothing concrete
- Orie: CHAPI and different options of using it?
- Tom: there is no redirect in the mobile device - goes directly
- Dick: Native app vs Browser app = different experience
- Dick: what if there is more than one wallet? Disambiguation
- Oliver: would it make a difference if IANA registered schema? iOS 14, you can opt in - became an option (David)
- Dmitri: need browser support; while exploring - a lot we can do with polyfills?
- David: Have you tried CHAPI polyfill on safari? - prompts you 2-3 times per interaction - hard to have good experience; all credentials may go ahead with CHAPI
- Tobias: Web Origin may not be storing credentials - ability of using the credentials goes away
- Bengo: why we need browser support
- Dmitri: OS support is needed; OPs have no way to know if your user/agent supports SIOP?
- David: Universal links - would that still work?
- Kristina: idea of proving integrity of the authenticator
- Mobile device that manages DID related
Zoom Chat
From Dmitri Z : +1 to record
From David Waite : +1
From Dmitri Z : yeah it’s been really intense, session wise!
From David Waite : There can be only so many participants named Boaty McBoatface
From Orie Steele : I made this tacky demo, using PWA, SIOP and CHAPI… https://chapi-siop.did.ai/
From Wayne Chang : ^ think you forgot “5g” in that link
From Orie Steele : https://self-issued.me/.well-known/openid-configuration
From Dmitri Z : @Orie - whoa, nice!
From Orie Steele : Its terrible ; Everyone is using that
From timcappalli : Lol @5G
From Orie Steele : https://github.com/decentralized-identity/presentation-exchange
From Kristina Yasuda : https://identity.foundation/did-siop/
From Dmitri Z : also on desktop...
From Orie Steele : Nahhh guys, we can keep using only RSA forever :)
From David Waite : FWIW Apple no longer recommends using custom url schemes, so its unlikely they will fix their current behavior.
From Vittorio Bertocci : @David I would have bet money that you would have commented on that :D
From Dick Hardt : Custom URL schemes are a security issue
From Orie Steele : Meaning opened:// ?
From David Waite : yes
From Orie Steele : Or openid:// ?
From Dick Hardt : That one too
From Orie Steele : :(
From David Waite : You can have universal links/app links, such as having an app or list of apps that will open (if installed) on links to https://self-issued.me or the like
From Dick Hardt : Universal links allow an app to own a URL
From Orie Steele : Confused… pretty sure mike jones owns self-issued.me
From David Waite : Think instead of progressive web apps, progressive native apps. Twitter.com links open a browser or a native app depending on if the native app is installed
From timcappalli : Yes, Apple already said they have plans to change this behavior, even for SIOP ; The user getting prompted isn't a great solution either
From David Waite : Yes, the owner of self-issued.me would have to say they authorize your app to act on behalf of their domain. But thats different than custom urls, which don’t have any root to base trust on
From timcappalli : A user is not going to know which wallet app they should use
From Orie Steele : So the proposal is use https://pwa.example.com instead of openid:// ?
From timcappalli : This is a much bigger problem than we're collectively making it out to be
From Oliver Terbu : openid:// is not mandatory
From Vittorio Bertocci : You can't support multiple wallet apps if they all need to sue the same domain
From Tobias Looker : @Orie I’ll cover with mine hopefully
From timcappalli : Which is exactly the problem ; How do you interoperate wallets then?
From Tobias Looker : @Vittorio agree
From Neil Thomson : https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md
From Dick Hardt : Wallets will need mobile OS support to work well
From timcappalli : Right, but they don't
From David Waite : Its also worth noting that App Store rules prevent an app from requiring another app to be installed, so there are extra limitations from how you could use _any_ installed wallet app.
From Tobias Looker : In short the browser has some role to play
From timcappalli : And an Apple or Google's response will be to say to use the OS's wallet
From Orie Steele : Progressive Web Applications are the future of identity.
From Tobias Looker : Either expanded protocol handling or something more advanced like CHAPI or WebIDs proposal
From timcappalli : And Apple hates PWAs too.. soo
From David Waite : (But universal links would give you an easy fallback of a web-based wallet)
From Orie Steele : Apple hates fortnite too
From David Waite : This sounds like I should create a session tomorrow :D
From Dick Hardt : All RPs would need to use the same universal link — what would that be?
From Dmitri Z : @David - top 10 things Apple hates? the session?
From timcappalli : That doesn't solve the issue though Dick ; Because if the user has multiple wallets, and most will, how do they know which one to choose if presented with a picker
From Dick Hardt : @Tim I think you are agreeing with me.
From David Waite : "Supporting wallets on mobile”
From timcappalli : This exists on Android today, but confuses users ; :)
From Orie Steele : Chapter 7 bankruptcy?
From Debbie Bucci : would supporting multiple wallets equate a union of all? Its not select the correct wallet but correct claim/did etc?
From Dmitri Z : @Debbie good question. So far, the design is - select the wallet first
From Tom Jones : Interesting question - each wallet would have its own access end point ; The RP would not understand that
From Dmitri Z : uuuugh, the “can’t remember which identity you used” is the WORST part of Nascar problem ; like, I’d put up with 50+ screens of logos, if the thing just remembered...
From Tom Jones : Yet - sux
From Orie Steele : yep
From Tom Jones : The browser could be the mediator, potentially, or any such password manager ; Something needs to track web sites for users
From David Waite : Credential Management API in W3C has a federation credential, but no browsers support it AFAIK
From Dmitri Z : @Tom @David - have you seen the Credential Handler API proposals? ; (there’s a polypill too, which deals with lack of browser support)
From David Waite : That ‘sort’ of thing, or the ‘WebID’ proposal, would be ways to have the platform help with persisting state for discovery
From Orie Steele : https://whatwebcando.today/credentials.html
From Ajay_Jadhav : @Tobias - do you think a KERI identifier be used with SIOP ?
From David Waite : If you have a single wallet, you could have it also be the place for state/discovery - but there’s no way to be the only provider of something for a platform :D ; (Except being part of the platform)
From Tom Jones : Should not care if keri or any self-issued id
From Ajay_Jadhav : Oh I see
From Oliver Terbu : @Ajay_Jadhav: no assumptions are made about specific DID methods
From Ajay_Jadhav : That’s cool
From Kristina Yasuda : but RP should be able to advertise which did method it supports
From Orie Steele : The security failure of preventing key rotation is the worst.
From drummondreed : It’s a non-starter
From Tom Jones : We would need the browser to support that
From Orie Steele : gg
From Dmitri Z : @orie it was proposed during a more innocent times.. before DIDs. :)
From Kristina Yasuda : "innocent"
From Dmitri Z : :)
From drummondreed : Yes, agreed. But we have to fix it now.
From Wayne Chang : Open questions around interactions between DID and WebID too
From Ajay_Jadhav : Haha - “innocent” :)
From Tom Jones : No interaction with web id ; Web id doesn’t care
From David Waite : @Dmitri CHAPI is very interesting. It does seem to promote issuer = holder, and I’d rather see a first-class credential type rather than wrapping things in “web” ; A set of first-class credential types, rather
From Dmitri Z : @David - can you say more? why issuer = holder?
From Tom Jones : Well - we can push some of this to the http header
From Dmitri Z : (oh agreed, I’d looove a first-class credential type)
From Oliver Terbu : CHAPI is just a message pipe, not more ; According to Manu @last IIW
From Dmitri Z : @Oliver - is true
From Orie Steele : I love seeing provider.example.com instead of self-issued
From Tom Jones : So this problem cannot be solved by openid ; That’s what nascar does
From David Waite : I could see CHAPI being used to register a bank credential at the bank, and then a request for that bank credential is processed by that bank including presentation of login/consent/disclosure.
From Orie Steele : Did uri could deference to http server...
From Tom Jones : So there is a solution to payments in process now
From Dmitri Z : @orie - that sounds dodgy :)
From Orie Steele : Why the did controller controls service….
From bengo : Kinda thinking about how everyone will be competing to register openid:// protocol handler
From Dmitri Z : @bengo - yeah, that is definitely one of the problems
From timcappalli : Biggest issue IMO
From Tom Jones : It has been registered already
From David Waite : My flappy bird clone already registered it, so back off everyone
From Dmitri Z : niiiice
From bengo : i mean by client apps, not in any ‘registry’ ; It’s fine if we just have to do it ‘because OIDC’, but why not also start specifying ‘did://‘ or others?
From Dmitri Z : @bengo - right, so, a ‘non-custom-url’ scheme solution for SIOP would definitely be the way to go
From Tom Jones : That is also a non-started
From timcappalli : Well, the actual string doesn't really matter ; Its the fact that everyone needs to use the same one ; It could be octopus://
From bengo : We could collaborate on open source code that accepts did://{method} uris, and *that open sourc eapp* can leverage things like uniresolver to provide a jump point ; (redirect_uris)
From Orie Steele : See also: https://github.com/whatwg/html/pull/5482/files
From timcappalli : Even then though, you could have multiple wallets for the same DID method
From bengo : Thank you orie
From Dmitri Z : @orie - oh INTERESTING (re that whatwg PR)
From bengo : Well, resolve the DID, and interrogate what ‘further authentication’ it prefers
From Debbie Bucci : Are the identities portable in both directions?
From drummondreed : Is that any different than having multiple devices you can accept a Signal message on? Or a iMessage?
From timcappalli : Right but the resolver has no idea which wallets the user has installed
From Dick Hardt : Or if the user has a wallet installed
From bengo : did document could say ‘preferredAuthenticatorCapabilities’ or something, and have a way of picking the best authentication with those caps (e.g. other wallet apps register with it?)
From Oliver Terbu : We have a lot of discussion in the chat. Please raise hand, so we can discuss it.
From Tom Jones : There is no did until the user releases one
From timcappalli : The only way I see this working is a DID wallet can register with an entitlement at the OS level and the browser can interrogate the wallets. Which obviously has its own issues
From Tom Jones : So first the web site needs to ask ; That doesn’t help the RP select one
From Vittorio Bertocci : "on the internet, no one knows you're a dog"
From timcappalli : Well, if the RP can detect you have Microsoft Authenticator, it could craft a custom URI scheme that would launch authenticator
From Tom Jones : The RP cannot detect any authenticator,
From timcappalli : Right, scroll up to my earlier comment about entitlements ; (New functionality by OS vendors) ; Similar to how payment apps on Android can have an entitlement to be an NFC payment provider ; Aka Samsung Pay
From Tom Jones : That was my comment about the password manager - it could do this
From bengo : +1 eventual OS integration, but we can prototype it as a ‘blessed app’.
From Dmitri Z : @bengo - have you seen how CHAPI prototypes it, through polyfill?
From timcappalli : There are no other options today ; Since we need interoperability ; @orie ^^
From bengo : @dmitri I have seen it, but I don’t always remember it ; refreshing ; i recall liking it
From timcappalli : If you want to invoke a specific wallet, that can happen like any other deep link today ; If you want to invoke "a wallet", that's where the problem is
From Dmitri Z : @timcappalli - agreed. there’s some ideas on how to improve that part. (at least on chapi) ; smoother onboarding
From bengo : Couldn’t the IDP show a page that’s like “Open with openid://“ vs “continue redirecting to https://* redirect_uri”. Ideally able to detect if openid:// is registered or not (but not by what)?
From bengo : kinda a bummer to redirect to openid:// directly if it’s gonna break for my mom
From timcappalli : I don't believe the browser can detect this today
From David Waite : Safari does not support registerProtocolHandler, obviously :-)
From Orie Steele : : /
From timcappalli : @Tom right
From David Waite : Others require it to start with web+xxxx
From bengo : “the platform” or “digital public infrastructure”
From Dmitri Z : yeah agreed (re platform). Like Web Authn does it
From timcappalli : The Android mobile payment implementation is a great example
From David Waite : e.g. it can’t be a standard protocol handler
From bengo : Is there already a ‘blessed app’ for handling openid:// from OpenID Foundation? YOLO or something?
From timcappalli : Default is not the issue though
From Orie Steele : Hearing in chat that it both MUST be and CANNOT be openid://
From timcappalli : 1 wallet is super easy
From Orie Steele : Still confused.
From Dmitri Z : @bengo - lol +1 to a YOLO app.
From bengo : YOU ONLY LEDGER ONCE
From timcappalli : This is like saying I want to open Outlook for one email domain and Mail.app for another email domain.
From timcappalli : ^^ that's what we need to solve
From bengo : I think that’s a feature
From timcappalli : Of course it has to work on desktop OS
From Carly Huitema : I have a flip phone!
From Orie Steele : Obligatory “ don’t you all have phones” out of touch blizzard employee comment
From bengo : Safari also didn’t allow serviceWorker until it did
From timcappalli : Safari ruins everything
From Christopher Hempel - esatus AG : Safari is the ne IE
From timcappalli : ^^ this
From bengo : Apple why don’t you just throw it away and build on Blink!
From Orie Steele : Fore real
From Dick Hardt : Mobile Safari == iOS
From bengo : help us out already! ; (joking)
From Dick Hardt : Safari really is the OS — not a browser
From Tom Jones : So apple uses, runs webkit which does sync with blink
From bengo : +1 to identifying non-nascar problems and opportunities, and organizing around what we’re interested in
From David Waite : +1
From Orie Steele : Can you fingerprint based on registered protocol handlers? ; I guess so
From David Waite : Agreed, don’t want to jump the queue but there’s a lot of value to split out the features that differentiate SIOP from regular OpenID Connect, and to extend OIDC to support other credentials
From Dmitri Z : @Orie - I don’t think you can. (fingerprint) ; I don’t think RPs have the ability to tell
From bengo : Oh look Apple’s not so bad. https://developer.apple.com/ios/universal-links/
From Dmitri Z : @bengo - heheheh you say that now :) it’s a little rough to use (for like React Native)
From bengo : Is that just a ‘bug’ or ‘todo’ for react-native, or technical limitation @dmitri?
From Dmitri Z : @bengo - apple policy / iOS limitation
From bengo : smh
From Dmitri Z : like, the native links are nicer than what came before, but still have their friction/limitations
From David Waite : Universal links are fun, I don’t know what happens when you have multiple apps though. Twitter for instance has like a dozen registered for twitter.com
From David Waite : (But most are internal staged builds)
From bengo : I believe you register them by path, not just domain (which is great)
From Dick Hardt : The app claims a universal link — so only that app can use it.
From David Waite : Yep! But they have many registered for each path :-)
From Tom Jones : The only way to get universal links to work is to have a single web site that everyone trusted to redirect the request -
From Dmitri Z : sad but true.
From bengo : It would let me ‘delegate’ from bengo.co redirect_uri to an iOS-registered app of my choice. OS would see that keys all add up, and just open the bengo app instead of the browser
From Oliver Terbu : I think it is not possible to have multiple apps for the same universal link. On iOS the link will be done based on a file that is hosted on https. The file contains info about the actual app that gets called. Right?
From Dmitri Z : @Oliver - right
From bengo : My knowledge about this is very old, so I am probably wrong about app-per-path
From Dick Hardt : Android has Android Apps that work *almost* the same as Universal Links
From David Waite : It doesn’t require a signed file anymore, just JSON at a .well-known location under HTTPS, and app metadata at deployment time saying you want to act on behalf of said domain.
From Dick Hardt : We are looking at using the links for client registration in GNAP
From Richard Astley : I think in iOS it's the last installed app that claims the universal link that can handle it.
From Tom Jones : Same w/ android
From bengo : refreshed on CHAPI. Yes I want this, and I’m happy to just use a PWA of my choice as a redirect_uri for a long time.
From Richard Astley : Android gives the user the choice of which app can handle the deeplink or the user can set their default choice.
From Dick Hardt : Android Apps allow user to override in settings — Android Apps is a newer mechanism for deep link management.
From Dmitri Z : in muggle terms - situation’s a mess. :) can’t have nice things. (currently.)
From Dick Hardt : https://developer.android.com/training/app-links ; Android App Links is the official name
From Orie Steele : So I am hearing that native apps are dead, and PWAs are the future :)
From Dmitri Z : @orie - yes. IN OUR HEARTS.
From Tobias Looker : https://bit.ly/3jmPmjs
From Adrian Gropper : IIW Savings Time
From Dmitri Z : ^ so true.
From Dick Hardt : LOL
From Kristina Yasuda : The calls info: https://openid.net/wg/connect/
From Dmitri Z : @Kristina - thanks!!
From Kristina Yasuda : BitBucket to file issues: https://bitbucket.org/openid/connect/issues? status=new&status=open
From Kristina Yasuda : requirements: https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md
From Tobias Looker : Link to slides https://docs.google.com/presentation/d/1mNkseYBxOs90whrgDonYyVZj3SqA2QGsn_pp-JpLapY/edit?usp=sharing
From Kristina Yasuda : Oliver's slides: https://docs.google.com/presentation/d/1K9jlC17uDC- JYiomcJI8cbZX8pXJwJZcr5Y8M_9c1T0/edit?usp=sharing
From Kristina Yasuda : we did have a proposal to talk to WebID WG as well
From Dmitri Z : oh excellent. (re webid wg)
From Tom Jones : So - I guess what the next step is - we create a proposal to the w3c WICG and see that they say ; I guess I could start one if no one else is used to that process?
From Adrian Gropper : Kim just answered my first question!!
From Tom Jones : Paw just makes the nascar problem worse ; pwa
From Orie Steele : Here is a demo PWA wallet: ; https://wallet.interop.transmute.world/
From Tom Jones : Yeah - Kim developed one too
From Orie Steele : Lets get the link in the notes :)
From Kristina Yasuda : PWAs could actually surpass NASCAR problem.. - it's already a url that does not need custom schema indirection?
From Tom Jones : No - because each pwa has its own URL ; So it only works if everyone uses Kims wallet
From bengo : CHAPI allows ANY PWA to register, not just Kim’s
From Orie Steele : Yep, I have similar code here: https://chapi-siop.did.ai/ ; Tries to blend the OIDC redirect with CHAPI ; But its pretty hacky…
From Tom Jones : Any one can register at any time - the user wold probably not understand the conflict
From bengo : I am the user.
From Dmitri Z : @orie - I was just looking at that demo. what’s the OIDC part?
From Orie Steele : @Dmitri it converts chapi responses to redirect URIs
From Tom Jones : Sorry - the user is my father
From Dmitri Z : @orie - oh fascinating
From Tobias Looker : Yeap uses CHAPI for the NASCAR problem but still interacts with the provider via redirect; An OpenID redirect; E.g a SIOP request
From David Waite : Well keep in mind, CHAPI only solves the problem if there is a single CHAPI polypill :D ; The CHAPI polyfill works by tunneling all the requests through a single web domain
From Kristina Yasuda : @Orie, your links are in the notes
From Orie Steele : Cool, I’m a big fan of PWAs… you can even do webNFC with them :) ; And web bluetooth
From Oliver Terbu : This work is not only about solving the NASCAR problem as pointed out earlier.
From Tobias Looker : Not on MacOS though :)
From Kristina Yasuda : good point, Oliver
From Tobias Looker : @Orie
From Tom Jones : If there is only one redirector it can work, just let me control that redirector
From Orie Steele : It works on macOS, just not safari
From Adrian Gropper : Can PWA work with hosted Intel SGX?
From Tobias Looker : Yeah sorry meant Safari
From Orie Steele : Yes, you can connect it
From Tom Jones : Paw works in browsers ONLY ; Its just a bunch of javascript
From Kristina Yasuda : paw works on mobile and web browsers
From Orie Steele : Sadly web authn does not provide general purpose hardware signing interface.
From Kristina Yasuda : link to this doc: https://drive.google.com/file/d/1LZHgcyaEm1CgtKucN0Gib4BvQ4m-_Cho/view?usp=sharing
From Tom Jones : Web author level two is in process - let me check that out
From Orie Steele : window.crypto.subtle can support non extractable keys ; And they can be used by PWAs ; From Orie Steele : But they are limited to old NIST crypto sadly
From Tom Jones : The spec on hardware protection is unclear - need to verify what android & apple actually do with that
