decentralized-id.github.io/2019-06-03-indieweb-dev-on-did.md at dfb69c25d3da1bffa0704350a8e3c7c2b69cccd3

Awesome-Mirrors/decentralized-id.github.io

Fork 0

mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-10-01 01:05:54 -04:00

⧉ infominer 00d651fb5c distribute media page

2020-11-23 12:58:27 -05:00

32 KiB

Raw Blame History

date

title

description

excerpt

date

Links

The Decentralized Identifier (DID) in the DNS

In-chat Links

https://docs.ipfs.io/guides/concepts/dnslink/
- DNSLink uses DNS TXT records to map a domain name (like ipfs.io) to an IPFS address. Because you can edit your DNS records, you can use them to always point to the latest version of an object in IPFS (remember that an IPFS object’s address changes if you modify the object). Because DNSLink uses DNS records, the names it produces are also usually easy to type and read.
- A DNSLink address looks like an IPNS address, but it uses a domain name in place of a hashed public key:
indieweb.org/checkin#Posting_checkins_from_clients

Peer-to-Peer DIDs

IndieAuth

{% include video id="EeCNlB7v08I" provider="youtube" %}

indieauth.spec.indieweb.org
- IndieAuth is an identity layer on top of OAuth 2.0 [RFC6749], primarily used to obtain an OAuth 2.0 Bearer Token [RFC6750] for use by [Micropub] clients. End-Users and Clients are all represented by URLs. IndieAuth enables Clients to verify the identity of an End-User, as well as to obtain an access token that can be used to access resources under the control of the End-User.
W3C Working Group Note 23 January 2018
- An IndieAuth implementation can implement one or more of the roles of an IndieAuth server or client. This section describes the conformance criteria for each role.
- Listed below are known types of IndieAuth implementations.
- 2.1.1 Authorization Endpoint
  - An IndieAuth Authorization Endpoint is responsible for obtaining authorization or authentication consent from the end user and generating and verifying authorization codes.
- 2.1.2 Token Endpoint
  - An IndieAuth Token Endpoint is responsible for generating and verifying OAuth 2.0 Bearer Tokens.
- 2.1.3 Micropub Client
  - A Micropub client will attempt to obtain an OAuth 2.0 Bearer Token given an IndieAuth profile URL, and will use the token when making Micropub requests.
- 2.1.4 IndieAuth Client
  - An IndieAuth client is a client that is attempting to authenticate a user given their profile URL, but does not need an OAuth 2.0 Bearer Token.
aaronparecki.com - Oath for the Open Web
- OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.
- While OAuth is a great framework for this, the way it has ended up being used is much more centralized and closed than prior efforts like OpenID 1. Every service that spins up an OAuth-enabled API ends up being its own isolated system. For example, if I want to build an app that can read someone's step count from FitBit, I have to first go register as a developer on FitBit's website in order to get API keys to use with their OAuth API
indieweb/indieauth #23#issuecomment-414152219
- 21:13 Loqi - [Zegnat] The table above has been updated with new statistics. This shows that rel="manifest" are equally as likely to be found on client pages as h-x-app. This Web App Manifests may be a more logical alternative than previously realised.
indieweb/wordpress-indieauth #127/files#diff-F81F3DFF36BF04B7A070D642C858E883
- dshanske commented on Feb 24- Returns a jf2 h-card in the token return on verification so the client can display name and user avatar on an application

indieweb-dev on RWoT-DIDs 2019-03-02

#indieweb-dev on DIDs 2019-03-02-chat log

16:14 @sandhawke - I don't think I have that level of interest to attend IIW - but I happen to be at RWoT right now, and that seems like a sweet spot for me to work on while I'm here. I just made this:
16:14 @sandhawke - Comparing WebIDs and DIDs
16:14 @sandhawke - which should perhaps have a column for IndieAuth
16:15 @sandhawke -although it's not quite the same type of thing, it kina is
16:15 @sandhawke -Anyway - DIDs seem to have a lot of momentum, so I'm inclined to fit webids & indieauth, which I much prefer, into the DID world
16:16 [aaronpk] -DIDs lost me when they make the assumption that blockchains are the only resolution mechanism
16:16 @sandhawke -In person everyone here denies that, and they seem to welcome other mechanisms.
16:17 [aaronpk] -any examples yet?
16:17 @sandhawke -Yes, "peer"
16:17 @sandhawke -Peer to Peer DIDs
16:18 [aaronpk] -Even just reading w3c-ccg.github.io/did-primer/#the-format-of-a-did-0 they casually drop a mention of blockchain as the only option
16:18 @sandhawke -dhh1128.github.io/peer-did-method-spec/index.html
16:18 [aaronpk] -I'd recommend revising that sentence if they want to not have people think that
16:18 @sandhawke -Yes, I know, and they know.
16:19 @sandhawke -But the best solution IMHO is just deploy something as nice and simple as indieauth
16:19 @sandhawke -But I agree there's a culture clash
16:19 [aaronpk] -From what I understand they have no interest in relying on DNS so that takes them completely out of the realm of working with current browsers or anything like IndieAuth
16:20 [aaronpk] -in theory you could make a dns resolver method for did and use domain names as the identifier and get close to something like IndieAuth
16:20 @sandhawke -Right.
16:21 @sandhawke -And it doesn't matter if they want that
16:21 @sandhawke -The end-users benefit
16:22 [aaronpk] -The other thing missing from DID is the authorization framework that comes with IndieAuth since it's built on OAuth 2.0
16:22 @sandhawke -They're working on DID-Auth, trying to figure out what that means. There are two papers about that this weekend, one from Microsoft.
16:23 [aaronpk] -The DID and OIDC groups weren't even getting along very well and while OIDC is way overkill for what we use IndieAuth for, its still more similar to IndieAuth than blockchain stuff is
16:24 @sandhawke -I agree re "way overkill", so I want to show how simple it can be. They're not the first "way overkill" people in identity / authn / authz.
16:25 @sandhawke -I mean -- maybe I should just go watch netflix -- this might be a silly waste of time, but I'm here, and it's a lot of smart and motivate people, so I can't help but wonder about trying to steer them a bit.
16:26 [aaronpk] -I would be very interested in what you come up with. I haven't had much luck in any of these conversations so far
16:27 @sandhawke -fair enough :-) Is indieauth.spec.indieweb.org pretty much up-to-date with your thinking?
16:28 @sandhawke -( sad not to see a change log from https://w3.org/TR/2018/NOTE-indieauth-20180123 )
16:28 [aaronpk] -Yep and https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web is a good explanation too
16:28 [aaronpk] - oh did I forget a change log section? I'll try to add that
16:29 @sandhawke - +1
16:30 [aaronpk] - If video is more your thing, I gave this talk at the W3C workshop youtube.com/watch?v=EeCNlB7v08I
16:30 [aaronpk] - its nice and short
16:34 @sandhawke - cool, pulling out headphones and wathching...
16:45 @sandhawke - ha - amused to hear Wendy's voice moderating the session
16:52 @sandhawke - I don't understand the value of public apps being identified
16:52 @sandhawke - (good video)
16:59 @sandhawke - I guess there's some attack it's intended prevent.
17:01 [aaronpk] - Yeah that's from OAuth. Prevents redirect interception by registering the redirect URL, and also helps the user not get phished
20:28 [jacky] - tbh as much as I'm for the whole DiD and what not
20:28 [jacky] - DNS is not going anywhere
20:29 [jacky] - as least for the people I aim to build for (like myself and then family to an extent)
20:29 [jacky] - DNS is straight-forward and more-or-less "reliable"
20:30 [jacky] - the only other idea I've seen thus far that was 'usable' has been docs.ipfs.io/guides/concepts/dnslink
20:30 [jacky] - (which still relies on DNS but one could augment a local DNS resolver to intercept these lookups)
20:51 [tantek] - listens intently. (also welcome (back) sandhawke!)
20:55 [jacky] - I don't know / wonder if a solution that's speech-friendly will arise
20:55 [jacky] - like if I can't say it out loud, it's incredibly hard to share
20:55 [jacky] - sure, I can just share a link
21:00 [tantek] - speechfriendly++
21:00 [Loqi] - speechfriendly has 1 karma over the last year
21:05 [swentel] - [tantek], yeah, I figured that it might be a useful link for people looking for my 'main' feed
21:06 [swentel] - also because currently in aperture, rel="feed" is ignored. So if people search feeds on realize.be, they will get microformats, but that's on my homepage, which is kind of useless
21:06 [swentel] - which makes me wonder whether I should remove microformat markup on the homepage maybe
21:08 [swentel] - (to be more specific, xray underneath ignores rel="feed", but that's technical detail)
21:09 [swentel] - other than that, fun experiments today with checkins and geocache, I'm getting excited by the location stuff in indigenous :)
21:10 [jacky] - hm so I saw a question about indieauth and "data", like in comparison to how OAuth2 gives you a blob of info post login
21:11 [jacky] - IndieAuth doesn't have to do that thanks to MF2; you can just pull what you need from their h-card but now I wonder
21:11 [aaronpk] - jacky: we actually started experimenting with this
21:11 [jacky] - would it make sense to show a specialized page in the value of the 'me' page? that changes b/c on the authenticated app?
21:11 [jacky] - aaronpk: oh?
21:12 [aaronpk] - trying to remember where we documented it? it was a quick thing during IWC Austin
21:12 [jacky] - oh man
21:12 [aaronpk] - GWG added it to wordpress and I added it to Quill
21:12 [swentel] - hmm, GWG opened an issue for me indigenous, there's probably a link there, let me check
21:12 [swentel] - indieweb/indieauth #31
21:12 [Loqi] - [dshanske] #31 Returning Profile Data
21:13 [jacky] - nice
21:13 [swentel] - that's at least the indieauth thing
21:13 [swentel] - maybe there's more?
21:13 [aaronpk] - yep thanks
21:13 [jacky] - indieweb/indieauth #23#issuecomment-414152219
21:13 [Loqi] - [Zegnat] The table above has been updated with new statistics. This shows that rel="manifest" are equally as likely to be found on client pages as h-x-app. This Web App Manifests may be a more logical alternative than previously realised.
21:13 [Loqi] - Further devel...
21:13 [GWG] - Although Zegnat pointed out it should be nickname not name
21:13 [aaronpk] - hrm I don't think it should be "nickname"
21:13 [Zegnat] - Hardly “should be”
21:14 [jacky] - that makes sense
21:14 [jacky] - b/c name is so vague
21:14 [jacky] - vs 'username', 'nickname', 'given name'
21:14 [aaronpk] - display name is more accurate
21:14 [Zegnat] - More like: I ** wondered if it should be more clear to expect a “display name” rather than a personal name (which I feel name is often used for)**
21:15 [aaronpk] - the other reason for doing this is it means it's easier to return private/sensitive profile data to apps without having to have a way to serve protected data from your home page
21:15 [GWG] - aaronpk, I agree with the idea and am willing to change to display name. It is still new and easy to adjust.
21:15 [jacky] - aaronpk: right
21:15 [Zegnat] - aaronpk, yes, that was a bit part of my reasoning over on GitHub :)
21:15 [Zegnat] - please comment with more details if you think I didn’t make that clear
21:16 [Zegnat] - s/a bit/a big/
21:16 [GWG] - If someone gives it another +1 I'll go make a PR
21:16 [swentel] - Hmm, I like name tbh :)
21:16 [aaronpk] - I also don't necessarily think "name" is a bad property for this, just need to make it clear that there is no expectation of a "real name" or "full name"
21:16 [swentel] - as it's consistent then
21:16 [aaronpk] - there isn't any expectation of that in this stuff anyway so I don't really see the problem
21:17 [Zegnat] - Except I felt there may have been an expectation of that in JF2, aaronpk. And the issue seemed to suggest using JF2 cards.
21:17 [GWG] - aaronpk, what if someone requests the theoretical profile scope?
21:17 [aaronpk] - Zegnat: what gave you the idea of that from jf2? jf2 shouldn't be defining any new semantics on top of the mf2 properties
21:18 [swentel] - GWG, do you have a link to the commit in wordpress?
21:18 [swentel] - Just for inspiration
21:18 [Zegnat] - “full/formatted name of the person or organisation” is the mf2 definition
21:18 [Zegnat] - Also, it feels to me like people have been using name on their h-cards a lot for full name currently
21:19 [GWG] - indieweb/wordpress-indieauth #127/files#diff-F81F3DFF36BF04B7A070D642C858E883
21:19 » [Zegnat] now has 3–5 seconds IRC delay, so discussing is going to be hard
21:19 [swentel] - thanks
21:20 [tantek] - hmm - we've been through this renaming loop before. name is display name, no need to ever change to "display name".
21:21 [Zegnat] - I do not want to change the name property in mf2 here [tantek]. I just want it to be clear that the minimal info returned from an IndieAuth endpoint is a display name specifically (and further names (?) may be available under something like a profile scope)
21:21 [tantek] - in the past other formats have tried to make distinctions between "display name" "full name" etc. and it just results in bad UX. in practice people enter into "name" what they want displayed. period. no need to futz or handwring about bikeshedding the property. it works
21:22 [tantek] - Zegnat, calling something display name then implies that other "name"s are not "display" and it just confuses people (implementers, users etc.)
21:22 [swentel - GWG, I've documented my experimental geo:uri;h=card on [indieweb.org/checkin#Posting_checkins_from_clients]](https://indieweb.org/checkin#Posting_checkins_from_clients) (but I'm not sure if that's the right place :/) ****
21:22 [tantek] - there is never a need in practice to ever "be clear" about "is a display name specifically"
21:22 [swentel] - just wanted to make sure it exists at least
21:22 [aaronpk] - side note: openid connect has "name", "family_name", "given_name", "middle_name" and "nickname" all under the "profile" scope, and tbh is an example of what tantek is talking about where the only one actually used is just "name"
21:22 [tantek] - that's a hypothetical concern from which no one has ever documented any actual harm ever
21:22 [GWG] - swentel, link to that under Micropub experimental as well.
21:23 [swentel] - GWG, on micropub extensions?
21:23 [GWG] - Swentel, yes, excuse me.
21:23 [swentel] - Ok, maybe it's better to move it there completely
21:24 [tantek] - aaronpk is correct, and opendid connect even there screwed up (inserted Western-centric assumptions by I'm sure the 100% Western white male openid connect "designers) by renaming vCard's "additional name" into "middle_name".
21:24 [tantek] - openidconnect--
21:24 [Loqi] - openidconnect has -1 karma over the last year
21:24 [GWG] - Do we have a theoretical use case for more than minimal data yet?
21:24 [tantek] - westerncentricassumptions--
21:24 [Loqi] - westerncentricassumptions has -1 karma over the last year
21:26 [GWG] - I return name, url, and photo because that was the minimum needed for a client to display. I am happy to return more behind a profile scope the day someone wants it
21:26 [tantek] - (note: " middle" is a layout/order specific label, not a semantic. in the past these same kinds of 100% Western white male format designers would have "first_name" "middle_name" "last_name", there's plenty of examples of bad old dead formats with that, programming examples in various "5 minutes to make your own social network!" type stuff etc.)
21:26 [aaronpk] - GWG: I'd hold off on anything further with this until we get more publishers and consumers of it
21:27 [jacky] - r^
21:27 [GWG] - aaronpk, I planned on it
21:27 [GWG] - I just was curious about uses
21:27 [GWG] - I have bigger problems right now
21:27 [tantek] - swentel - I think if you put rel="alternate" on the link to your h-feed page then it may be discoverable. I believe rel=feed was deprecated (even dropped by WHATWG HTML for lack of interest / implementations)
21:28 [swentel] - [tantek], oh, interesting, I'll give that a try yes!
21:28 [GWG] - Really? I just added a bunch of rel feeds
21:28 [GWG] - I can't keep up
21:29 [GWG] - I thought alternate was an alternative view of the same page and feed was a different page
21:29 [GWG] - What is rel-feed?
21:29 [Loqi] - rel-feed is the standard for linking to multiple (potentially alternative) h-feeds from a site's homepage using the code rel="feed" on those links indieweb.org/rel-feed
21:30 [jacky] - yeah same
21:30 [jacky] - re: G WG
21:31 [tantek] - no feed discovery is done via rel=alternate type="insert your feed mime type here"
21:31 [tantek] - like since forever
21:31 [GWG] - That's the way I am using and consuming it
21:31 [aaronpk] - whoa swentel indieweb.org/Micropub-extensions#Location_checkin_information
21:31 [tantek] - folks here have been trying to get rel=feed off the ground again but TBH I'm unsure about it's feasibility
21:31 [GWG] - What is feed discovery?
21:31 [Loqi] - feed discovery is a way to, given someone's home page, discover their feed or feeds that they publish indieweb.org/feed_discovery
21:31 [aaronpk] - that's like an embedded h-card in a geo URL?
21:31 [aaronpk] - URI
21:31 [swentel] - aaronpk, yeah, works great .. (at least for me)
21:32 [GWG] - aaronpk, yes it is
21:32 [tantek] - aaronpk you had it right 🙂
21:32 [swentel] - I can post checkins and geocaches now from indigenous, with pictures, all in one go :)
21:32 [swentel] - it's GREAT ;)
21:32 [aaronpk] - [tantek]: re: geo URI? I thought URLs had to be resolvable
21:32 [tantek] - swentel++ wow
21:32 [Loqi] - swentel has 27 karma in this channel over the last year (48 in all channels)

#indieweb-dev on IIW 2018-08-19

#indieweb-dev on IIW 2018-08-19-chat log

17:08 [aaronpk] - No, IIW
17:09 [aaronpk] - but all the OAuth IETF people will be there
17:09 [tantek] - IETF people take IETF i-d more seriously than rando domain with proposals
17:09 [kevinmarks] - IIW is a good place to socialize specs certainly
17:09 [aaronpk] - I wonder how much of this I can write in the next 2 hours
17:09 [aaronpk] - need a name tho
17:10 [kevinmarks] - OpenAppID
17:10 [aaronpk] - Oh no
17:11 [kevinmarks] - I was being facetious
17:11 [tantek] - [kevinmarks]: based on what evidence of successful specs to come out of IIW socialization?
17:11 [tantek] - kevinmarks++
17:11 [Loqi] - kevinmarks has 7 karma in this channel over the last year (30 in all channels)
17:11 [tantek] - OpenAppID++
17:11 [Loqi] - OpenAppID has 1 karma over the last year
17:11 [aaronpk] - OAuth came out of IIW
17:11 [kevinmarks] - OAuth 1.0 had a lot of groundwork done at IIW
17:11 [kevinmarks] - yes
17:12 [tantek] - no that's a myth. OAuth came out of a mailing list started by Blaine at Twitter
17:12 [aaronpk] - A lot of it was done at IIW regardless of where it started exactly
17:12 [tantek] - the actual work was done by a small set of folks on a limited-write, public-readable mailing list
17:12 [kevinmarks] - yes, but getting the yahoo and Google people in the room with him at IIW really helped
17:12 [tantek] - it was an interesting model of standards development by email
17:13 [tantek] - OAuth did not "come out of" IIW
17:13 [tantek] - that's the myth
17:13 [kevinmarks] - that helped get the mutual trust necessary to contribute to the mailing list
17:13 [tantek] - it came out of a limited-write, publicly readable mailing list started by Blaine
17:13 [kevinmarks] - I didn't say that, I said "a good place to socialize specs"
17:13 [tantek] - aaronpk said that
17:14 [aaronpk] - What I meant was OAuth would not have succeeded if it had not been discussed at IIW
17:14 [kevinmarks] - I dragged several google auth people across the street to IIW, then they joined the mailing list
17:15 [kevinmarks] - the real bonding experience was them hotpatching the spec and mitigating the replay attack at that foo camp
17:16 [tantek] - yes the Open Web Foo hotpatching of OAuth 1 to fix the security problems was key
17:16 [aaronpk] - I need a name that gets across that client registration is replaced by DNS
17:16 [aaronpk] - I would use “implicit client registration” if “implicit” didn’t already have existing meaning in OAuth
17:17 [tantek] - "URL client registration" ?
17:17 [kevinmarks] - Zero Registration per ZeroConf
17:18 [tantek] - or NoReg per NoSQL
17:19 [tantek] - shortened to "NR"
17:19 [tantek] - how do you handle client registration? we use NR for that
17:19 [tantek] - "ZR" works just as well
17:19 sknebel - client lookup?
17:21 [aaronpk] - PKCE is a great name because it’s easily googleable and also pronounceable (pixie)
17:23 [tantek] - aaronpk: Zero Registration shortened to: ZoRg
17:23 [tantek] - all the Fifth Element fans will love it
17:23 [aaronpk] - zorg omg
17:24 [tantek] - YES

32 KiB Raw Blame History Unescape Escape

Contents

Links

Related

In-chat Links

Peer-to-Peer DIDs

IndieAuth

indieweb-dev on RWoT-DIDs 2019-03-02

#indieweb-dev on IIW 2018-08-19

32 KiB

Raw Blame History