- From: <msporny@digitalbazaar.com>
- Date: Thu, 11 Jan 2018 14:49:32 -0500
- To: Credentials CG <public-credentials@w3.org>
Thanks to Manu Sporny for scribing this week! The minutes
for this week's Credentials CG telecon are now available:
https://w3c-ccg.github.io/meetings/2018-01-11/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Decentralized Identifiers Task Force Minutes for 2018-01-11
Agenda:
https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit
Topics:
1. DID Harmonization
2. Spec Updates
Organizer:
Drummond Reed
Scribe:
Manu Sporny
Present:
Drummond Reed, Manu Sporny, Dave Longley, Markus Sabadello,
Christopher Allen, Sam Smith, Christian Lundkvist
Audio:
https://w3c-ccg.github.io/meetings/2018-01-11/audio.ogg
Manu Sporny is scribing.
Drummond Reed: Thanks to Manu for the proposal, good discussions
on the mailing list.
Drummond Reed: One thing to help advance it today, wrote up some
thoughts that build on that proposal - we should discuss that
today.
Drummond Reed: Do others have thoughts about that proposal that
we should discuss? Key insights to drive to spec closure?
Drummond Reed: Harmonization proposal is here:
https://lists.w3.org/Archives/Public/public-credentials/2018Jan/0022.html
Drummond Reed: Dan Buchner at DIF said Microsoft is doing
DIDs... going over requirements w/ them.
Drummond Reed: This is stuff is advancing quickly... Microsoft
giving talk at Davos, decentralized infrastructure is one of the
things being talked about by MS head.
Drummond Reed: Kim Cameron is thoroughly involved and behind
effort that Microsoft wants to build API support into Azure
Active Directory.
Drummond Reed: On to specifics... sent URL to the mailing list
-- link forthcoming...
Drummond Reed: URL for the Google doc Drummond is presenting and
inviting anyone to edit/comment -
https://docs.google.com/document/d/1z8o2VPjvXIw6-KrxGTdSPfOshDlBGmj0MhH3QJXS0eg/edit#heading=h.hgyrqixmo1f0
Drummond Reed: Since proposal was published, had DIF meeting,
had chat w/ Markus and Sam.
Drummond Reed: Let's dive into this - quickly go over five
specific things
Topic: DID Harmonization
Drummond Reed: I found explanation of tree and graph
harmonization helpful. Because of requirements, you can do tree
and graph oriented processing... designed to do that, editorial
recommendation.
Drummond Reed: Next items are more substantive.
Drummond Reed: From a tree-oriented perspective, I'm calling
'id', 'publicKey', and 'service' core.
Drummond Reed: Theme of minimalist is that we just need those
'tree' properties and can get stuff done - Manu's proposal
allowed that you can have both tree-oriented and graph-oriented
in the same document if you design it elegantly enough.
Drummond Reed: If you look at it from the tree-oriented
perspective, satisfied on extensibility model - graph / richer
perspective... from tree-oriented perspective, if you look at
these three properties, if you look at authentication as a
service that may not need an endpoint, then the same thing can be
described as a service w/o an endpoint. Type property could be
used in that way.
Dave Longley: Hmm, slightly concerned that what Drummond is
describing might end up turning "services" into a "bag"
Drummond Reed: Service type descriptor -- protocol for doing
authentication, doesn't use an endpoint, in band protocol... but
there can be a different version of that... DIF planning on new
WG for DID Auth - site you're logged into w/ different endpoint,
different protocol, service with endpoint.
Drummond Reed: Moving on to public key property... owner
property -- JSON-LD signatures requires it... other key
descriptions may use it, it may be inferred, when it is required
it's clear why it is.
Dave Longley: About the owner property, if it's assumed, then
what we recommend that we do the same thing that we did with
'id'... resolvers inject that property where it should be... some
DID methods might not have ID, produced/implied... but you inject
it into final DID document when you're done. We can inject into
key information in same way as key ID.
Markus Sabadello: Basically, DID document will have owner for
every public key.
Drummond Reed: It's either explicit or implicit.
Manu Sporny: So the only thing that throws a wrench into the
works there is that there are potentially DID ledgers that might
sign things [scribe assist by Dave Longley]
Manu Sporny: We dont' do the implied thing in Veres One, we'd be
careful to include owner before signature [scribe assist by Dave
Longley]
Manu Sporny: The one wrench in the works is that auto-included
signature would invalidate the signature. [scribe assist by
Drummond Reed]
Manu Sporny: Injecting the owner field post signature would make
it invalid. [scribe assist by Dave Longley]
Manu Sporny: It's not a blocking thing, just considerations.
[scribe assist by Dave Longley]
Manu Sporny: Specifically about owner, keep in mind that this
isn't just about DID documents but it's useful outside in the
general Web. If you express keys on the public Web, for example.
[scribe assist by Dave Longley]
Manu Sporny: We do need owner elsewhere, we can't assume who the
owner is. It can be kind of dangerous to assume, it could turn a
programming mistake -- a DID document authoring mistake into a
security vulnerability. We should consider heavily about
presuming certain values are certain values when it comes to
things like key material. [scribe assist by Dave Longley]
Manu Sporny: Want to be explicit, not implicit. The owner of a
key that's listed may not be the DID -- you may list keys that
belong to other poeple. [scribe assist by Dave Longley]
Manu Sporny: You may have M of N signatures, for example, where
you list other people's keys. [scribe assist by Dave Longley]
Manu Sporny: We should be careful and have a further security
analysis on this. [scribe assist by Dave Longley]
Manu Sporny: Moving make to the key references stuff, that's
fine, we were hoping that would happen. [scribe assist by Dave
Longley]
Manu Sporny: Key references looks good. Core tree properties,
I'm wondering if something was missed. Christian on the mailing
list said that he likes the idea of purpose and application being
split out from the general key description. [scribe assist by
Dave Longley]
Manu Sporny: The proposal on the mailing list did just that.
Authentication/encryption/whatever, uses following the tree based
path or the graph property. [scribe assist by Dave Longley]
Manu Sporny: We were not going to put that in with the key.
[scribe assist by Dave Longley]
Manu Sporny: That means the core tree properties needs to have
that there. Not sure if we're challenging that or what here.
[scribe assist by Dave Longley]
Manu Sporny: This raises the question about where does the
purpose go. I thought there seemed to be general consensus on the
mailing list that the purpose should be outside of the key, not
part of the key description. [scribe assist by Dave Longley]
Drummond Reed: Just wanted to do an overview, didn't want to get
into discussion in depth.
Drummond Reed: In response to Manu, what we've illustrated here
is what was proposed, but it recognizes that the 'authentication'
type, referencing public key used for authentication... another
way to look at that - what does the type represent... that's a
service, an in band service, doesn't need a separate endpoint.
Drummond Reed: If you cross-reference a key from a service
description, you're effectively doing the same thing... it's
clearly an authentication service - described in type of that
service... more of a tree-oriented description... but
accomplishes the same thing.
Drummond Reed: Part of the original proposal, big believer,
doesn't matter where type is defined, type for service, type for
authentication -- it should have a spec... what is this type for.
Drummond Reed: You can also model this as a service - that's
what I'm trying to illustrate here.
Dave Longley: I'm concerned about this approach... anythign can
be a service, so let's make a giant bag of services.
Dave Longley: To a certain extent, we can argue that keys are
services as well - if we make our bag generic enough, but if we
do that, we lose core ideas of splitting it out - clear purpose
and relation to follow to get to the information you need to get
to.
Dave Longley: I like the idea of following a certain relation to
where we want to go - same arguments apply for bag of keys.
Christopher Allen: Sorry I’m late. Too many Thursday calls.
Drummond Reed: Just want to reinforce that write up is about
tree-oriented processing viewpoint -- do not think it's a
repudiation/replacement of graph-oriented viewpoint. I'm not
trying to say we shouldn't have/define well known graph contexts.
Drummond Reed: Folks who want to do it that way can do it that
way... we can define how a DID Document can be used from a tree
vs. graph-based standpoint...
Drummond Reed: It's fairly elegant, both world views can be put
together.
Drummond Reed: Folks who have a graph-oriented view can see how
it can work from a tree-based and vice-versa.
Drummond Reed: This is not to say we shouldn't have the exact
set of fields being proposed and spec should say "for graph
oriented view -- here are standardized properties"
Drummond Reed: The DID context that we'll be defining in the
spec, will be defining these base properties...
Drummond Reed: Those properties are you can only use the raw
name for in that context.
Dave Longley: What do you mean by "can only use"?
Drummond Reed: To clarify - property names map to items in
JSON-LD context.
Dave Longley: Yes
Drummond Reed: If someone wants to come along and define the
service, they have to do that in their context.
Dave Longley: Yes, they can do that... they can define a new
property in the DID document, they can extend w/ a new context.
Dave Longley: They can also define a context for their
application -- it's a straightforward context.
Drummond Reed: What term do you use to describe properties and
property names defined in the JSON-LD context.
Dave Longley: That's called a "term"
Drummond Reed: Is there native vs. extension?
Dave Longley: No, not needed... there is not root context for a
JSON-LD document?
Drummond Reed: How would we refer to "terms" defined in DID
Document JSON-LD context that we'll define?
Drummond Reed: A DID Context term can be used to refer to
something in JSON-LD DID Context.
Dave Longley: Having other properties at top level is not
incompatible w/ tree processing model... different place to put
that information.
Dave Longley: So, items at the top level are compatible w/ tree
and graph processing models.
Drummond Reed: I'll retract that statement... you can process
graphs as trees.
Dave Longley: A tree is a subset of a graph.
Drummond Reed: What's being proposed in B is that it's not that
it's a tree model, it's a minimalist view of description - a
simple model of description, not as rich as graph-based approach.
Drummond Reed: Basically, you can reference things from a
service instead of via authentication.
Drummond Reed: Manu's proposal says that if you have to
reference a key, you have to do it via the authentication
field... if you have an authentication service w/ a endpoint, is
that not a service? or is it?
Manu Sporny: All I wanted to do was that we are way down the
extensibility rabbit hole. [scribe assist by Dave Longley]
Dave Longley: When we're minimizing - we could reduce properties
in document... or alternative - minimize on differences between
approaches.
Dave Longley: You don't have to worry about tree and graph
distinction - the more important thing is to minimize towards
reducing differences.
Dave Longley: I'm not clear on why it woudl be better to go in
that direction.
Sam Smith: It's not clear what the purpose of the authentication
block is.
Sam Smith: In my mind, there is a target of authenticating
someone for some purpose. Are we authenticating owner of DID
document? Are we authenticating some other service or protocol
that is yet to be determined. I'm very concerned about the
latter. Generically specifying authentication. If we were talking
about just authentication to the DID document, but then we're
talking about a protocol for how we authenticate DID documents.
Sam Smith: If you could clarify that, that would be helpful.
Manu Sporny: Where are we putting the purpose and application
related to the key. That's not an answer to Sam yet. If we remove
authentication, it follows that we have to put application and
purpose somewhere. [scribe assist by Dave Longley]
Manu Sporny: The assertion is moving it to the service array and
we're not putting it in the key. I wanted to clarify ... it's not
pointed out in the proposal, but that has to be true -- that info
has to go somewhere. [scribe assist by Dave Longley]
Manu Sporny: My assumption is that application/purpose is going
into service descriptions now, but I don't know what those look
like I can't easily analyze what's being proposed. That's an
option question on section B. [scribe assist by Dave Longley]
Manu Sporny: Sam, I think you're right... the reason we had
authentication and encryption was because there's a general use
case for authenticating as the entity associated with the DID.
[scribe assist by Dave Longley]
Manu Sporny: That's a use case everyone has. [scribe assist by
Dave Longley]
Manu Sporny: What you say is true that it can be a bit
concerning when you use "authentication" and when you don't. On
the mailing list, I explained that that property expresses the
purpose and application fairly clearly and it's a meta protocol.
It's not a service with an endpoint. [scribe assist by Dave
Longley]
Manu Sporny: I think what's being argued is that the services
array could contain both services with endpoints and these other
things. [scribe assist by Dave Longley]
Manu Sporny: We have a specific set of use cases where the
authentication would be used, one is Web-based authentication ...
[scribe assist by Dave Longley]
Sam Smith: As soon as you say a set of use cases and you sign
something and the something you are signing is authenticating you
as the owner and controller of the DID document. [scribe assist
by Dave Longley]
Manu Sporny: Yes, you're signing something to authenticate as
the entity associated with the DID document. [scribe assist by
Dave Longley]
Sam Smith: That makes a lot more sense. We want to authenticate
control of the DID document and we're going to have a spot for
that specific purpose and define a protocol for that. And every
different protocol for that needs a document somewhere else.
[scribe assist by Dave Longley]
Manu Sporny: Yes, and that's what the authentication suites were
about. [scribe assist by Dave Longley]
Manu Sporny: It defines exactly what the protocol would be and
my assumption was that the services would have an endpoint ...
and now they don't necessarily have one. [scribe assist by Dave
Longley]
Sam Smith: So we could have authentication suites be subsets.
It's the same information, where do you put it? [scribe assist by
Dave Longley]
Manu Sporny: The argument for splitting it out would be to be
very explicit about these containers. It's the anti-bag argument
-- don't let the bag lose meaning because it has everything in
it. [scribe assist by Dave Longley]
Manu Sporny: Maybe authentication suites only go in the
authentication bag. For the encryption bag, only encryption
suites/protocols/mechanisms go in there. [scribe assist by Dave
Longley]
Drummond Reed: Drummond invites others on the call to weigh in on
this topic.
Manu Sporny: That seems to be the discussion we keep having --
how generic do we make these containers. We tend to push back
when it goes to such a level that you can just put anything in
the container. [scribe assist by Dave Longley]
Manu Sporny: That's why you split those things out. [scribe
assist by Dave Longley]
Sam Smith: I would say that that is not specific enough. [scribe
assist by Dave Longley]
Dave Longley: +1 To getting more specific!
Sam Smith: Having an authentication bag and an encryption bag
isn't specific enough. [scribe assist by Dave Longley]
Drummond Reed: This seems more and more an argument about the
best way to do description (of both keys and services).
Sam Smith: We're saying we want to have this more specific but
still generic way to do authentication. I disagree. If we're
going to authenticate DIDs we should outline that protocol and
standardize or have a set to suggest to standardize on. Until
we're prepared to do that, let's make it simple and just do keys.
[scribe assist by Dave Longley]
Manu Sporny: I was with you up until your last sentence. [scribe
assist by Dave Longley]
Dave Longley: I believe we have a need for DID auth, not a need
so much for generic keys.
Dave Longley: DID auth is super important, IMO.
Drummond Reed: I like that we're getting down to the nub of it,
different viewpoints on description -- the more specific, more
complete the spec behind a type, the more it can be used to
identify what's needed. It's a different type of description, not
discoverable in the graph in a DID document, defined/identified
via URL/mapping.
Sam Smith: I agree that DID auth is important, essential But DID
auth is not Auth for any other purpose
Drummond Reed: It's one way of doing description, graph model,
authentication - neither approach is wrong, if we are not going
to convince one another that we - both methods supported and away
we go.
Sam Smith: As soon as you expand beyond DID auth you are on a
slippery slope
Sam Smith: That's fine .. but let's pick a relation that's for
DID auth specifically and make that thing then. [scribe assist by
Dave Longley]
Sam Smith: +
Christopher Allen: I have similar concerns, new bags emerging -
adding more and more things in that nothing in DID would be
anything but how to do stuff w/ the DID.
Christopher Allen: Stuff in DID Document is only about DIDs --
e.g. IDs, Verifiable Credentials, etc.
Christopher Allen: I wanted to be far more specific - part of
the challenge is we're calling these topics areas generic words -
rather than being "encryption" -- be more specific.
Christopher Allen: Maybe it should be "didAuthentication"?
Christopher Allen: Even the section name sounds like a bag.
Dave Longley: I'd be happy if we got this down to a bikeshedding
discussion
Dave Longley: Vs. a modeling one.
Drummond Reed: It really boils down to this - how much
description is in the value vs. the properties.
Sam Smith: Is this about DIDs/ DID Auth - we specify it... if it
is about somethng else, we punt.
Sam Smith: Let's have a section that is a reference that has
information for protocol/protocol set for doing DID Auth.
Manu Sporny: +1 To limiting to that.
Dave Longley: +1
Dave Longley: Let's agree that this is how we ought to model
things ... and then just pick the things we are ready to
standardize, like a place to do DID auth.
Sam Smith: Then we can all agree that this is essential, and we
should say how to get key material for DID owner/signer/etc.
Drummond Reed: Types of authentication for entity identified by
the DID... other auth protocols -- absolutely authentication
services out there, what do you do w/ authentication service?
authentication or do you put it under service?
Drummond Reed: What about FIDO, OpenID, WebAuth -- there are
subprotocols/profiles.
Drummond Reed: They are different protocols, part of a family,
are they all defined there? If we had a branch, it would be for
that set of DID Auth stuff?
Dave Longley: Yes, it's PURPOSE is for authenticating the subject
of the DID
Sam Smith: We have an DID authentication branch that points to
the key bag, both people can be happy, but we limit discussion to
auth branch to being DID Auth... any other form of authentication
is off of the table. If we want to add something to that bag in
the future, I don't think we'll ever get there to limit to
essential things to move forward.
Manu Sporny: Manu: +1
Dave Longley: +1 Authenticating the DID entity is essential
Dave Longley: And that's what we all want need.
Drummond Reed: So Drummond proposes two questions: 1) should we
have a LIMITED "authentication" branch that is only about DID
auth? 2) What do we do about other authentication services (e.g.,
OpenID Connect)?
Christopher Allen: Yes, if you do a DID Auth, you can do other
objects, then you can authenticate additional things --
progressive trust, verify via DID Auth, then you can go further.
Dave Longley: +1 To bootstrapping post authentication of the DID
entity.
Drummond Reed: Two questions I'd love to close on the call are
above.
Christopher Allen: +1 To bootstrap first
Dave Longley: Doing OpenID or whatever to authenticate yourself
as some other thing (or whatever) belongs somewhere else, not in
the DID auth bag we're talking about.. .. that was *always* the
intention from my perspective.
Christian Lundkvist: I'm cool with limiting "authentication" to
DID Auth
Christopher Allen: +1 Did authentication bag
Dave Longley: I dont' think we need to call it
"didAuthentication" because it is a *relation* where the DID is
the subject ... from a graph model perspective, but i'm happy to
bikeshed.
Dave Longley: To be clear, that was *always* the intent
Drummond Reed: It was always the intent, but that was not clear
-- term meant that it's for all authentication.
Drummond Reed: This also answers question - what about other
authentication services? There are endpoints, we need services,
any service except for authentication... someone can say that's a
service... as long as we're clear -- about our guidance, if
you're going to do DID Auth, it belongs in this branch.
Dave Longley: I think the reason we weren't making it clear, if
you look at it from a graph model perspective, the subject of the
DID is explicitly stated and the property is authentication, so
it's clearly about DID Authentication.
Christopher Allen: Yes, if you think of it from tree-way of
thinking, you need extra hint that it's didAuthentication - good
observation, maybe there are other places where graph way of
thinking may need clarification.
Christopher Allen: In effect, we have a tendancy to want to do
things at once, in my head, it's more of a progressive trust
model... we talked about it in CCG and what is progressive trust
blog post that I did.
Christopher Allen: Authentication isn't an atomic operation, it
is a process where you start w/ little things
Drummond Reed: Christopher has a good point about property names
("terms" in JSON-LD parlance) - the preferred semantics depends
on whether you are looking at the term from the tree-oriented
view or the graph-oriented view. Dave's point illustrates that.
Christopher Allen: I encourage you to focus on this being part
of a bootstrap process. There may be things before and after,
it's not authenticated or not... you're authenticated enough for
the scenario. There is no end to authentication.
Christopher Allen: The process stops short of real world truth.
Dave Longley: And unfortunately, the meaning in the "tree model"
is mostly derived from specs only, there's no explicit underlying
data model.
Dave Longley: But we can be clear about the meaning in our spec
-- even if you get it intuitively with the graph view.
Markus Sabadello: I agree with having branch called
authentication, should be used for DID-based authentication. Not
sure if it should be limited to DID Auth - limit it to one
specific protocol, OpenID would be a service? Wouldn't service
also use key material used in authentication branch?
Markus Sabadello: Would it apply to all services/endpoints?
Dave Longley: OpenID, you'd be authenticating some other piece
of information, from graph model perspective, authenticating as
entity that owns DID, if you want to authenticate as something
else, that goes somewhere else.
Markus Sabadello: I didn't mean authenticate someone else, I
meant using different protocols.... but OpenID might where you
identify as DID.
Markus Sabadello: Different protocol, uses same key material as
DID auth... should use what's in authentication branch.
Dave Longley: We'll have to be more careful about DID auth
Dave Longley: It means authenticating a subject of DID document.
Markus Sabadello: Good question.. is "did auth" a specific
protocol ?
Christopher Allen: No, it is method specific
Drummond Reed: OpenID does the same thing... what this
highlights is that there is a specific protocol for DID Auth,
what do we do for v2?
Christopher Allen: If openID wants to do a method spec, then sure
Drummond Reed: I do understand that we can create a new
relation... branch for each type of auth service - I get that,
ones that are services are easy... but where does it end up?
Drummond Reed: Does it force us to pick one path or other.
Manu Sporny: I'd like us to claim victory while we can and move
on. [scribe assist by Dave Longley]
Manu Sporny: We have agreement, so the core tree properties id,
publicKey, authentication (or didAuthentication), and service
[scribe assist by Dave Longley]
Manu Sporny: And we're only going to talk about DID auth and put
that in the authentication field. [scribe assist by Dave Longley]
Markus Sabadello: +1 To id, publicKey, authentication, service
Manu Sporny: We can discuss things further and make solid
progress. I'm wondering if we have enough to say we've got the
core properties, id, publicKey, authentication, and service and
put that into the spec and implement against it. [scribe assist
by Dave Longley]
Manu Sporny: We still need to have a discussion about what goes
int those fields, but it's significant progress. [scribe assist
by Dave Longley]
Drummond Reed: Good constructive point. Please think about that.
[scribe assist by Dave Longley]
Sam Smith: I agree, let's declare victory before we lose it. :)
Sam Smith: In example that manu provided, there are two types -
crypto type in key... application/purpose type in
"authentication".
Dave Longley: To sam-- yes, but *what* are you authenticating --
it's the *subject* of the relation, which we want from a graph
modeling perspective.
Drummond Reed: If you approach authentication from service
standpoint, you could also have authentication protocol
identified by type.
Dave Longley: So that's all fine from our perspective.
Dave Longley: +1 Its essential, let's call it out in its own
branch.
Sam Smith: Authentication is an essential feature of a DID
document, so I'm ok calling that out in its own branch.
Drummond Reed: That branch is for DID authentication
protocols... if you're using any other auth protocol, put it in
service branch... but we expect this to be multiple protocols
over time, how do we design it over time. This resonates w/ me.
Dave Longley: This generalizes for other identity documents on
the Web (which makes what we've been doing with Linked Data
signatures ... it's why we want it this way! :) )
Drummond Reed: I can see why encryption wasn't brought up in the
same way -- they really meant it in context of key/protocol...
key negotiation protocols.
Drummond Reed: What about key negotiation protcols? combination
of key type which is cryptographic operation... like
Diffie-Hellman - I need to talk about BOTH keys AND protocol.
Sam Smith: We can be specific by nesting types where each type
adds new information that isn't essential to previous level of
Type... or have long branches that break up types into individual
fields (but that's slippery slope of too much algorithm agility).
Drummond Reed: Markus brought up discomfort w/ public keys,
auth, and services - but wanted to invite Markus to weigh in.
Dave Longley: Another reason , somewhat historically, putting
authentication at top level is to not specify DID Documents as
anything different. Included in that thing could be "how to
authenticate" all of that matches well with this approach, you
can re-use other types of protocols - whether somethin gis being
resolved from DID Resolver... or URL Resolver, it just works.
Drummond Reed: Dave is making the point that authentication of a
DID subject is special enough that it should be elevated to a
top-level branch.
Dave Longley: I think in this conversation "DID auth" is generic.
Markus Sabadello: I'm very comfortable with this approach,
authentication branch should be limited to DID Auth - concrete
protocol. Dave was talking about something more generic, just
subject, not DID owner. I don't think authentication branch
should be restricted.
Dave Longley: It's not restricted to a particular protocol but is
specific to authenticating the DID entity.
Manu Sporny: +1 ^^ That
Drummond Reed: If we say in the spec, "This is for
authentication for DID Subjects", that accomodates the different
protocols that could be used to do that, then I do believe in
what Dave and Manu have been saying... DID Auth is special.
Drummond Reed: It's not just because some forms of it won't have
endpoints... let's say OpenID sees DIDs take off, if they want to
do a profile of OpenID DIDAuth, then what I'm hearing is "Ok,
then you're defining something, type/protocol that belongs in
that authentication branch.
Markus Sabadello: Maybe OpenID could use what's in
authentication branch.
Dave Longley: I agree that it could go both ways, this would be
the place to put something if you HAVE to do a new OpenID
protocol.
Drummond Reed: Then why wouldn't we just use a service
description... back full circle.
Sam Smith: I think we don't know the answer yet because we
haven't walked through OpenID yet. There are many iterations of
this, let's not try to solve all of those problems yet, let's
agree that "authentication" meets needs of tree and graph based
model and we need auth and key reference and a type field that
specifies protocol and now we can move on to specific protocols.
Manu Sporny: +1000
Drummond Reed: There are two things 1) This is a DID Auth
protocol, and 2) it does not have a separate endpoint.
Dave Longley: And when we say "DID auth protocol" we mean, it is
for authenticating the entity identified BY THE DID.
Drummond Reed: Any protocol that fits those items goes here -
happy w/ that definition.
Christopher Allen: I'm in general agreement with that... if
OpenID wants to create a DID Method, that's the other way they
can do things. Methods do have a certain ability to do things
their own way -- if there is enough information in a DID Method,
then you can proceed/reuse information.
Christopher Allen: There are escape valves here.
Drummond Reed: Anyone have any issues with this?
Dave Longley: Victory victory victory!
Markus Sabadello: I'm comfortable with it.
Christopher Allen: Please write!
Manu Sporny: Should I start drafting spec text?
Drummond Reed: Yes, now have a clear enough picture... will
point back to this exercise of how hard it is for well meaning
people to agree while staring at the same document.
Christian Lundkvist: +1 From me! :)
Dave Longley: \O/
Topic: Spec Updates
Manu Sporny: I was able to get David Chadwick as a spec editor
and get the whole process working on his machine. He was able to
do PRs and edit -- so you and I, Drummond, can go through the
same process. [scribe assist by Dave Longley]
Drummond Reed: Perfect. [scribe assist by Dave Longley]
Manu Sporny: Ok, we'll do that. [scribe assist by Dave Longley]
Manu Sporny: There are some sections that needs to come out,
like the authorization section (did method specific). [scribe
assist by Dave Longley]
Dave Longley: (Or goes into a common optional spec)
Drummond Reed: Ok, I'm happy. If you want to take what's there
to get us to the next baseline and we start working against, I'm
more than happy. Pull out what you need to comes out, put in what
you know needs to go in. I'll be happy to engage at that point.
And assign action items to me. [scribe assist by Dave Longley]
Drummond Reed: Can't wait to get it done. [scribe assist by Dave
Longley]
Manu Sporny: I'll try to get the spec restructured and then you
and me doing PRs against specific sections. [scribe assist by
Dave Longley]
Drummond Reed: CONGRATS and thank you everyone for persisting
through to get to this point where we can get down to drafting.
Received on Thursday, 11 January 2018 19:50:00 UTC