- From: <msporny@digitalbazaar.com>
- Date: Thu, 25 Jan 2018 14:45:06 -0500
- To: Credentials CG <public-credentials@w3.org>
Thanks to Susan Bradford for scribing this week! The minutes
for this week's Credentials CG telecon are now available:
https://w3c-ccg.github.io/meetings/2018-01-25/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Credentials CG Telecon Minutes for 2018-01-25
Agenda:
https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit
Topics:
1. DID Harmonization PR
2. Encryption
3. DID Fragment Identifiers
Action Items:
1. Drummond to get with the folks working on the service name
solution to turn it into a concrete proposal.
Organizer:
Drummond Reed
Scribe:
Susan Bradford
Present:
Mike Lodder, Manu Sporny, Drummond Reed, Jan Camenisch, Kyle
Hartog, Christian Lundkvist, Dave Longley, Sam Smith, Adrian
Gropper, Susan Bradford, Markus Sabadello, Chris Webber
Audio:
https://w3c-ccg.github.io/meetings/2018-01-25/audio.ogg
Susan Bradford is scribing.
Topic: DID Harmonization PR
Manu Sporny: https://github.com/w3c-ccg/did-spec/pull/41
Manu Sporny:
https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html
Manu Sporny: Spec should now be aligned with consensus from the
last call. Place to put public key, authentication suites.
... Compact algorithm seems to work for those involved in the
calls.
Drummond Reed: So delegation is one of the open issues
Manu Sporny: No method on delegation right now, will probable be
method specific initially.
Manu Sporny: Experimental items are marked as such in the doc.
Drummond Reed: Manu, can you share links to the new registries?
Drummond Reed: Example 2 Service does not have a property. Manu:
That was intentional.
Manu Sporny: If you have a service endpoint you can put it
there, but you do not have to do that.
Mike Lodder: Is the "type" optional? It seems to just be a
description tag
Kyle Hartog: Q - Example 10 lists encryption as experimental.
Where will encryption be in DID Auth?
Manu Sporny: This is still up in the air, good argument for both
ways (authentication/encryption)
Dave Longley: Btw, i would think we're talking about
"keyAgreement" for TLS, not "encryption"
Jan Camenisch: I've got a question related to pseudonyms, i.e.,
when a public key is a pseudonym
Drummond Reed: Encryption for DID Auth protocol - it is a
separate property will DID Auth end up under auth or service? If
all it needed was the type and the key I'm using, these 2 entries
under authentication is what that is for.
Drummond Reed: Justification for separation - you don't need to
define it as a service.
Manu Sporny: If people want to messaging encryption as a
service, it can be done in encryption.
Mike Lodder: In both the service and public key, are they
optional or required?
Manu Sporny: They are not optional.
Dave Longley: Example 6
Mike Lodder: Will those types be defined?
Drummond Reed: We will have a set defined in the DiD off that
will be published. There will be a spec that defines that in
here.
Dave Longley: We should put some URL examples in there
Drummond Reed: Short names established by DiD context, mapped to
global url's.
Dave Longley: As that's how they will appear when using the DID
@context if they were not defined by the group
Jan Camenisch: Public keys could be anonymous, in some context
you might want to limit to one identity
Manu Sporny: That sounds method specific.
Manu Sporny: You could get hyper specific on the key you put in
the did doc. Once you spend the key, that can be called out.
Manu Sporny: You can annotate that key for a specific
assumption.
Manu Sporny: In the JSON world, if they reuse that terminology
from JSON LD you can do it the same.
Jan Camenisch: Fields in the public keys you could add a field
for context...
Topic: Encryption
Dave Longley: Do we have a use case for putting encryption in
this doc?
Mike Lodder: Use a srvice, and the public key is used as a back
up. Private key held elsewhere. Key encapsule
Dave Longley: Use cases seem to fall under key agreement
Mike Lodder: +1 To change to keyAgreement
Drummond Reed: Inherent under the service, or key type when
identifying the key. We are open to call encryption out if its
needed.
Manu Sporny: Mike-lodder, do you think we should have
KeyAgreement as a form of authentication suite? or separate from
authentication?
Dave Longley: We have to have use cases for anything we put in
here.
Kyle Hartog: We dont want to make the assumption that we will be
operating in a tls channel, so the way would be to use an
encryption key.
Drummond Reed: The DID Auth - the protocol would be assigned a
URL, the name would go into the JSON LD
Drummond Reed: If there are multiple keys, then we have a
different situation. We only allow for one key right now.
Dave Longley: The encryption to the service would be listed in
the service block.
Christian Lundkvist: What we are discussing could also be in a
service end point. DID Doc is like a root of trust.
Drummond Reed: I agree with Christian that the DID document could
be just a starting point for key negotiation.
Dave Longley: +1 Seems like the most common/expected approach
Drummond Reed: As he is pointing out, it may be used only for
provisioning. It could be a common design pattern.
Christian Lundkvist: Assume we have a tls channel, have an
authentification protocol for username and pw.
Manu Sporny: Interesting proposal
Drummond Reed: The challenge with an assumption of a TLS channel
for DID auth is that it requires bootstrapping decentralized
identity solutions from centralized CA PKI.
Dave Longley: I think we're talking about two different things
Dave Longley: 1. Getting around the CA system
Dave Longley: 2. Authenticating once you have a TLS channel
Dave Longley: Where in #1 you try and do both at once
Dave Longley: But with #1, that's really messy on the Web. (doing
both at once)
Manu Sporny: The design pattern you are pointing out christian
is upgrades.
Dave Longley: So combining both approaches would be more ideal,
IMO.
Dave Longley: And you can do #2 without doing #1 if you trust the
CA system.
Mike Lodder: You have to be careful with that and address two
issues: the absence of forward secrecy for all data, and the
replayability
Drummond Reed: It does seem like including "encryption" as a
defined branch of a DID document is on the bubble, and we should
not include it if no one has a good use case for it.
Dave Longley: +1 To using authentication or service
Manu Sporny: Key agreement - Could we say that did auth or tls
will either go in an auth bucket or service bucket?
Markus Sabadello: Sorry I need to leave.. I don't see any big
problems with this version of the spec, and I'm also looking
forward to further discussing the details of DID Auth.
Drummond Reed: Mike Lodder makes a good point about encryption
for key agreement being something that should be done outside of
the DID document.
Mike Lodder: +1 To remove encryption
Kyle Hartog: +1 To removing from spec
Dave Longley: +1 To removing encryption
Dave Longley: "DID-TLS" is a good name for this
Dave Longley: And it should use TLS
Manu Sporny: Remove encryption from the spec
Drummond Reed: End up with just a set of keys, and a set of
types, and the pattern we have in there will be just fine.
Dave Longley: You could also just list a certificate in a DID
Doc.
Dave Longley: And then bootstrap that way
Dave Longley: (It's like certificate pinning, but putting it on
the blockchain instead of in the client)
Drummond Reed: Decision: take "encryption" out of the spec.
Kyle Hartog: I've looked at finding a way to translate an auth
key in a DID Doc into a CA. Not sure how it would be done, but if
it could it wouldn't require any changes to TLS. Also not an
eloquent solution to the problem.
Drummond Reed: Feature discussed early on that solves a
significant problem of being able to map a did doc that maps to a
url. Name element (property) for a service.
Dave Longley: Yeah, not elegant but would be a better "plan B"
than rolling a new TLS
Dave Longley: IMO.
Sam Smith: Ex 2. we have the id which is the did, then the
public key with the same did. In key rotation, how do I change
the auth in this example? . Earlier we only had the frag
identifier.
Dave Longley: Btw, we may want to use a full ID for simplicity
instead of using a fragment identifier:
https://github.com/w3c-ccg/did-spec/pull/41/files#r163934080
Manu Sporny: Fragment ID - resolved are specific to JSON LD.
Frag dont necessary work the same across specs.
Manu Sporny: Frag ID's are resolved on the base url.
Drummond Reed: Example 2 has reference to frag identifier that
just has a hash sign. Why is it not the same reference?
Manu Sporny: It could be.
Sam Smith: That is how it used to be.
Sam Smith: Why woud you not always do it with the hash sign?
Manu Sporny: If you are a machine, you will want to work with
the full url.
Sam Smith: Are we doing examples for machines or for developers?
... This needs to be spelled out very specifically in the spec
for developers.
Sam Smith: Examples should be consistent
Manu Sporny: All examples will use frag identifiers
Manu Sporny: Authorization did doc you may point to other keys,
you will have to include the full url.
Dave Longley: Recommend we use the full url everywhere.
Manu Sporny: As long as we are consistent.
Mike Lodder: As a programmer, I useually end up using an
absolute path 90% of the time. Agree we should use full url.
... Make processing rules clear.
Kyle Hartog: +1 To full path. Helps remove any convolution that
may occur
Sam Smith: Explain the variants somewhere else.
Dave Longley: A foolish consistency...
Topic: DID Fragment Identifiers
Sam Smith: The original hardening doc V3 had a write up on meta
data syntax component.
Drummond Reed: DID Hardening Spec Proposal V3:
https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit#heading=h.abon80m52d50
Sam Smith: Its in Sec 10.
Sam Smith: With the current way that did frags are being
proposed with JSON ld, would that conflict with using rfc6901 or
being able to reference other parts of the did spec using
rfc6901?
Manu Sporny: This is JSON pointed
Manu Sporny: This cold be problematic for JSON/JSON ld
compatibility.
Sam Smith: JSON LD is the problem.
Manu Sporny: The group wants compatibility between the two. We
use identifier. When there is not an identifier, that is when it
gets hairy. Need use cases for this.
Dave Longley: What's the use case?
Dave Longley: You can have the same problem if you pick other
technologies -- many technologies are mutually exclusive
Sam Smith: Concern: If assume so much with JSON LD we wall off
any other options.
Drummond Reed: I think what Sam is proposing is that the spec say
that the DID spec supports JSON Pointer.
Drummond Reed: Summary - th did spec in the fragment portion, we
say were going to support json pointer for syntax. Make one
modifying assumption - if it references a did fragment
identifier.
Drummond Reed: If you follow with a slash, now your'e using a
json pointer.
Sam Smith: Does anyone see where that is not compatible?
Sam Smith: 2 Proposals in Ex 10 on fragments.
Sam Smith: Is that 2nd proposal compatible?
Sam Smith: The shards are not keys, they are parts of keys
Sam Smith: Are we truly supporting naive json and json ld?
Drummond Reed: Sam is going over an example of why he wants to
use JSON Pointer style fragments to support references within
naive JSON documents.
Drummond Reed: Dave thinks there may be some compatability
problems with supporting JSON pointer.
Dlongely: would expect there will be some compatibility problems.
If you see a slash after, you would have to do something
different.
Manu Sporny: Trying to map as cleanly as possible what web
developers use in general.
Chris Webber: I just joined
Manu Sporny: Accept that fragments do have some special
encoding.
Manu Sporny: Fragment identifier resolution is defined by the
media type spec [scribe assist by Drummond Reed]
Drummond Reed: Manu feels that using a "brittle" approach for
addressing within a DID document (and he considers JSON Pointer
such an approach) could be dangerous.
Manu Sporny: If we are going to give this stuff special meaning,
it means that we are talking about something that is a new media
type (not json/jsonld0
Dave Longley: Actually, i don't think there would be any
incompatiblity with JSON-LD libraries right now ... it would just
be a layer on top you'd have to run -- and JSON-LD users would
have to make sure to frame the document a certain way (and know
what that frame is)
Drummond Reed: This means that DID documents would need to be a
separate media type.
Dave Longley: Which might not be possible
Drummond Reed: I would very much like to avoid having to make DID
documents a separate media type
Sam Smith: In the current did spec, we have a special meaning
for a fragment.
Time check: 6 mins
Manu Sporny: The library that processes the url is highly
specific library
Manu Sporny: Fragment ids for did's re more complex, then call
in pointers.
Manu Sporny: Concern this will lead to security issues.
Drummond Reed: Q - do you still want to make a specific proposal
for json syntax? Sam: yes, but dont want that to hold it up.
Drummond Reed: Sam will consider making a future proposal about
supporting JSON Pointer.
Manu Sporny: If pathing is that important, we should address did
paths.
Drummond Reed: Drummond is open to talking about DID paths.
ACTION: Drummond to get with the folks working on the service
name solution to turn it into a concrete proposal.
... Are we going to keep scheduling these meetings through Feb?
Manu Sporny: Any objections to merging this change set next
Tuesday?
Mike Lodder: +1 To merge
Mike Lodder: After review
Drummond Reed: Any objections to merge this PR in by next
Tuesday?
Drummond Reed: Continue this meeting next week? Yes. Pick items
that are blocking people. Bring those to the meeting.
Drummond Reed: If you have items that are blocking, send them to
the mailing group, and Manu and Drummond to be added to the
agenda.
Thanks everyone!
Received on Thursday, 25 January 2018 19:45:32 UTC