- From: <msporny@digitalbazaar.com>
- Date: Thu, 14 Dec 2017 14:59:38 -0500
- To: Credentials CG <public-credentials@w3.org>
Thanks to Susan Bradford and Christian Lundkvist for scribing this week! The minutes
for this week's Credentials CG telecon are now available:
https://w3c-ccg.github.io/meetings/2017-12-14/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Credentials CG - DID Hardening Task Force Minutes for 2017-12-14
Agenda:
https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit#
Topics:
1. Current Status of DID Hardening Discussions
2. Options for Keys / Authentication
3. Option #D
Resolutions:
1. Eliminate Option #3 from the discussion choices as described
in this email:
https://lists.w3.org/Archives/Public/public-credentials/2017Dec/0046.html
Organizer:
Drummond Reed
Scribe:
Susan Bradford and Christian Lundkvist
Present:
Drummond Reed, Susan Bradford, Nathan George, Markus Sabadello,
Mike Lodder, Christian Lundkvist, Sam Smith, Brent Zundel, Kim
Hamilton Duffy, Adrian Gropper, Manu Sporny, Dave Longley,
Christopher Allen
Audio:
https://w3c-ccg.github.io/meetings/2017-12-14/audio.ogg
Susan Bradford is scribing.
Topic: Current Status of DID Hardening Discussions
Drummond Reed: Any conclusions or options that came out of the
worldview conflicts email thread?
Adrian Gropper: The worldview dichotomy appears as we try to
standardize the way scopes are handled. OAuth and UMA on top of
OAuth seem to have an allergy to linked data protocols (I don't
understand why). Meanwhile linked data could be a solution to
making scopes clear and reliable in UMA (but I have no experience
with RDF).
Manu Sporny: Suggests that we not dwell today on the
philosophical level. How does it look IN the did doc?
Christopher Allen: Just arrived.
Topic: Options for Keys / Authentication
Drummond Reed: Manu has done a good job of framing the options.
We will go through the shared doc and drummond will make notes
Drummond Reed: Options are here -
https://lists.w3.org/Archives/Public/public-credentials/2017Dec/0046.html
Christopher Allen: Scared about some of these approaches comes
from SSL. Everything was adaptable. it made it very difficult.
Created cypher suites. Could be added onto, etc. Ended up having
several hundred cypher suites. Desire to keep it standard in a
high lever spec that everyone supoorts scares him. BTCR - there
are a bunch of things we cannot easily support.
Sam Smith: @Chris if both algorithmic agility and cypher suites
are bad what is your proposed solution
Christian Lundkvist: Wants to speak on option 3. Believes it
goes against what DID docs are supposed to do.
Drummond Reed: +1 To Christian's point that "if nothing about key
management and description is standardized, we won't have
interop"
Manu Sporny: +1 To that as well... we're trying to standardize
stuff here...
Manu Sporny: Specifically, at least authentication mechanisms and
how you express them.
Christian Lundkvist: Any method could support whatever cypher
suites that makes sense to them. Provide a list of standards that
can be used.
Manu Sporny: So, -1 to Option #3
Drummond Reed: +1 To having a list of standard cryptosuites to
choose from - that's been the proposal for standardized key
descriptions all along.
Drummond Reed: Yes, -1 to Option #3
Kim Hamilton Duffy: Options A,B,C. It can be confusing to
implementers if the elements are expressed component wise. Of the
three options, B would be a non-option. Does not cluster
Kim Hamilton Duffy: Her preference would be closer to Option A.
Wants to understand more about implosionist suites.
Drummond Reed: Thought a firm decision was made that the access
rules for updating the did doc are method specific.
... For methods that want to describe those capabilities, we
should do a different spec.
Drummond Reed: Agrees that key management service description
are in scope and have been all along.
Drummond Reed: Scope questions broader than key management has
come up.
Drummond Reed: How to express the overall model for key
management - keeps hearing there are certain combinations that
are best practices. Put all the umph behind that. Need to
encourage best practices.
Nathan George: +1 To both ledgers and applications leveraging
keys in a DID document AND having some interoperability scope to
those keys (to keep things functionally compatible)
Manu Sporny: Is there an option that was not expressed in his
email?
Drummond Reed: +1 To Dave's point that DID docs need to be able
to express two categories of key material: 1) keys or proofs
necessary to update the DID doc, 2) keys or proofs needed by
various applications.
Manu Sporny: Can we eliminate any of the options now?
Drummond Reed: Totally agree that we want to standardize any
common functionality across ledgers, including any usage of keys
that needs to work across ledgers.
Manu Sporny: -1 To not standardizing. Wants to hear what Sam's
thoughts are on Option 3. WHere do we go from there? We may be
able to reifne the problem set of what we are trying to solve.
Sam Smith: Option 3 is not what is what he is proposing. He was
proposing where almost everything is in the key type.
Drummond Reed: Sam explained that what he thinks should be bound
is the cryptographic suite, operation, and version.
Dave Longley: +1 To what Sam is saying about key type -- it's
what we do with Linked Data Signature suites
Dave Longley: (Which includes a "year" as a version)
Manu Sporny: +1 To what Sam is saying -- which is exactly what
Linked Data Signatures do via SignatureSuites.
Drummond Reed: Wondering if we can get a subset of this group to
agree on a "best practice for key descriptions" and then
recommend that back to the group?
Sam Smith: If you want cryptography that progresses in time, you
have to have a way to have the hooks for management. Ability to
revoke, and maintain.
Dave Longley: Putting the year in the suite also is a strong
indicator of version vs just "version 1" or "version 2"
Christian Lundkvist is scribing.
Drummond Reed: Thanks Christian.
Nathan George: Chairs: at some point should we close the queue so
that we can propose to eliminate options or make some type of
decision?
Sam Smith: The purpose would not be in the type, you can use a
signing key for authentication or other things
Drummond Reed: @Nage yes, but I don't know the procedure for
that. Can you suggest it?
Christopher Allen: General problem - there may be a problem with
combinatorial complexity when doing cipher suites as well
Kim Hamilton Duffy: My confusion is cleared up: Sam clarified
that purpose isn't in the type, which is consistent with LD
signatures.
Drummond Reed: Ok
Christopher Allen: What do we need to define in order to do CRUD
operations on the DID document?
Drummond Reed: The problem is that I'm not sure we've reached
that point in the discussion.
Christopher Allen: We might be trying to do too much
Dave Longley: And "application" or "application class" shouldn't
be in the type either, IMO. -- but we need to capture that in a
relation.
Kim Hamilton Duffy: I'd like to understand the differences
between option B and C; can someone speak to that more
Kim Hamilton Duffy: ?
Sam Smith: Key material is in the key bag for the universal
purpose of key management that is discovery to enable suite
upgrades rotation revocation. The specific purpose is in a
different branch than the bag with a reference to the key
material in the bag. This is now a graph not a tree
Drummond Reed: Everyone in favor of having the ability to do
CRUD on DID document. Option #3 might be enough to support that,
but this kicks interop key mgmt down the road (needed for
applications)
Sam Smith: Specific purpose is authentication, etc etc
Drummond Reed: My reaction to #3 is "lets' not say CRUD on DID
docs is the only thing we'll do"
Drummond Reed: Evernym has contract with DHS to do key mgmt part
- so it's important
Manu Sporny: Can we have a vote to eliminate option #3 from the
list of key descriptions?
PROPOSAL: Eliminate Option #3 from the discussion choices as
described in this email
Nathan George: +1
Dave Longley: +1
Kim Hamilton Duffy: +1
Mike Lodder: +1
Drummond Reed: +1
Christian Lundkvist: +1
Sam Smith: +1
Manu Sporny: +1
Christopher Allen: +0
RESOLUTION: Eliminate Option #3 from the discussion choices as
described in this email:
https://lists.w3.org/Archives/Public/public-credentials/2017Dec/0046.html
Manu Sporny: Kim pointed out differences between #3 and #C
Manu Sporny:
https://w3c-dvcg.github.io/ld-signatures/#signature-suites
Manu Sporny: ChristopherA says need to be careful about algo
agility, Sam agrees in general
Manu Sporny: We have suites in JSON-LD, need to cut down the
suites to a small amount that makes sense
Sam Smith: Jose bad yes too much agility
... JOSE/JWT stack has issues with algo agility, very loose wrt
that
Manu Sporny: If you like restricted algo agility suites JOSE
might not be a good choice
Manu Sporny: Sam + evernym folks like #A a lot
Sam Smith: But JWT is good not for algo agility but because
signatures are not embedded in graph
Drummond Reed: +1 To Manu's point that we want to be very
specific about what a key can be used for.
Manu Sporny: Folks seem to be against total combinatorial
agility, which is good
Manu Sporny: In option B we break out what a key can be used for
Christopher Allen: Can application and purpose be one value?
Kim Hamilton Duffy: I thought Sam was supporting something closer
to option C, but he's on the queue and can speak to that
Kim Hamilton Duffy: I.e. separating out purpose
Dave Longley: I would think so (application and purpose captured
in one value ... or even application "class" to allow multiple
applications to use it)
Christopher Allen: Thus type: signaturesuite apppur:
vcissuersigning
Manu Sporny: In #C you encode the application of the key through
the relation.
Sam Smith: I am proposing an option D
Dave Longley: In option C the relation could include purpose and
application/application class.
Manu Sporny: In #B the application lives with the key
Sam Smith: Option D is option C is expressed as a compact string
plus a version which is not in C. and then Purpose is in its own
branch
Dave Longley: "Purpose" is also not fully pinned down, IMO --
whether we're talking about crypto operation only or something
higher level... which is why things like "authentication" as a
purpose is a bad idea, IMO. ... that's not a crypto operation,
it's an application level consideration
Drummond Reed: Have a lot of regard for crypto-folks in this
group. Those who have the battle scars and care about this, if
those ppl came together and come to consensus that I would
probably support it.
Dave Longley: It should be done as a relation only ... you can
use this key to authenticate that this entity, for example,
signed something.
Sam Smith: I propose "option D"
Drummond Reed: Should we propose that a subset of ppl hammer out
a proposal and bring it to the group?
Christopher Allen: The date is a version
Christopher Allen: RSACryptographicSigningKey2017a
Topic: Option #D
Sam Smith: Option D above: Take #C, add a version, combine it
into a small type string
Dave Longley: I like OptionD *minus* the key encoding. (Sam
didn't mention encoding)
Sam Smith: Values are a tuple, not optional
Drummond Reed: I'm also intrigued by Sam's Option D proposal
Sam Smith: Application purpose exists somewhere else in the
bag/graph
Dave Longley: OptionD ... RsaCryptographicSigningKey2017 ... and
then "publicKeyPem" contains the key material in PEM format
(other terms can specify it in other formats)
Kim Hamilton Duffy: Me too, but also wondering about status of
encoding in this world
Sam Smith: Somewhere else is specified the ontology etc, we
decide if we want to standardize some of that
Christopher Allen: One of things that drew me in to this
community was the signature suite date that specified the version
Christopher Allen: Willing to concede that same signature/proof
system could have application + purpose
Christopher Allen: Can see specific crypto methods supporting
signing and not encryption etc
Drummond Reed: Interesting point ChristopherA brings up about
"signcrypt" keys
Sam Smith: @ Manu not signature suites but cryptographic suites
at a given level of cryptographic strength
Christopher Allen: If I can be persuaded there is a concise list
of application + purpose then I'm willing to accept that. Not
sure I like the idea of separating application + purpose into two
fields
Christopher Allen: I still lean to proofs.
Manu Sporny: I find Sam's option #d intriguing. If Sam can type
it up would be good
Manu Sporny: Pros/Cons:
Dave Longley: It requires every new application to maintain an
ontology for key types
Drummond Reed: +1 For Option A including a year (for versioning)
and it makes it easier for developers to exactly specify a key.
Manu Sporny: #A Pro: Very specific, can't get more specific.
Almost impossible for devs to screw up. Cons: May be in a
combinatorial problem. May be 50-100 types springing into
existence
Manu Sporny: Option #A could turn into bad combinatorial problem
Manu Sporny: #B Pro: No combinatorial problem. Con: Developers
can easily screw it up if they only pay attention to some parts
Dave Longley: Imo, key purpose, where that refers to permitted
crypto operation only, should always be baked into the key type.
Dave Longley: Application/application class/other kinds of
higher-level "usage" should be done via a relation (DID subject -
relation - key)
... #C Attempts middle ground: No need to do purpose in the
type. Don't open the misimplementation problem as badly.
Drummond Reed: Drummond wonders whether we should have a poll to
see if we can eliminate Option B?
Manu Sporny: Looks like we're going back to signature suites and
saying they're a good idea. The sig suites right now are put on
"proofs" and not
Manu Sporny: Looks like we're going back to signature suites and
saying they're a good idea. The sig suites right now are put on
"proofs" and not "key material"
Manu Sporny: In suite we are binding the key type, application
and purpose together. It's more of an application suite
Dave Longley: +1
Sam Smith: I just posted an email in the "worldview" email
thread
Dave Longley: Binding of application or "higher-level use" should
be done through relation, IMO.
Sam Smith: Strong agreement with almost everything Manu said.
Don't think everything should be in type. Everything except
purpose should be in type. also version
Drummond Reed: +1 To Sam's point that version belongs in the key
type description.
Sam Smith: Then we break discussion of key managment/material
away from the usage
Sam Smith: Everyone wants their worldview to be a MUST. Not
always possible, can use SHOULD
Dave Longley: +1 Yay for Sam.
Sam Smith: Limit the MUST to the simplest, most universal things
we can agree on. Other stuff can be SHOULD
Sam Smith: Signing is a crypto operation inside a crypto suite
Drummond Reed: +1 To our job here being to describe key material
within a cryptographic suite
Sam Smith: Every operation is tied to the same suite
Sam Smith: Bigger than signature suites - we're talking about
cryptographic suites
Drummond Reed: +1 To specifying cryptographic suites
Sam Smith: Signing, MACs etc all from the same suite
Sam Smith: Suggests key bag with crypto suites, then application
specification elsewhere in the graph
Dave Longley: *And* we should make sure that we don't let the
*meaning* of that signature bleed into that suite, that's
application layer stuff... for example, does a signature mean
"someone made a claim about me (verifiable credential)" or does a
signature mean "sign me into this service" ... both of these are
"authentication" -- but it's up to the application to decide what
that means.
Sam Smith: Type should be "cryptographic suite, operation, and
version". The value is the actual key itself, and the id is a
unique way to reference that key. [scribe assist by Drummond
Reed]
Kim Hamilton Duffy: Option D is very promising to me.
Cryptographic suites make sense as an entity on their own. The
final type "blesses" a valid combination (along with a version)
Drummond Reed: Is there enough interest in option #D that we
should write it up?
Kim Hamilton Duffy: +1
Mike Lodder: +1 Option D
Drummond Reed: Other proposal is to have a subgroup to think
about it and come back with a proposal
Sam Smith: @ChristopherA as long as its a tightly bound tuple or
string its that same to me
Mike Lodder: +1 Examples
Sam Smith: Option D is written up in an email.
Drummond Reed: There are no examples yet
Christopher Allen: I'd really like to see a start list from Manu
of applicationpurpose are already implied by current
implementations
Drummond Reed: Drummond notes that keyref is also something
that's needed in service descriptions
Manu Sporny: A bit concerned about key ref in option D. Still
assumes we have a bag of key material
Sam Smith: For key mgmt the bag allows us to do key discovery.
Drummond Reed: Drummond notes that this question - about having a
"bag of keys" - is one of those worldview conflict areas.
Manu Sporny: Huge discussion to have there. Want to focus now on
the stuff we're almost there on
Manu Sporny: The "type" specifier doesn't have to be a long
string with combinatorial issue
Christopher Allen: The name of a cryptosuiteV doesn't constrain
it — it is the spec that is behind that name of suite points to.
Manu Sporny: We should go out and specify all the suites there
are and see how many there are
Manu Sporny: Type should be crypto suite or application suite,
need to see JSON or JSON-LD markup to see if we're on same page
Manu Sporny: Others can weigh in on key material
Dave Longley: Need to be careful with "value" since more than
one format to represent a key
Dave Longley: In general think it's a good approach
Drummond Reed: Dave points out that there's more than one format
for serializing a key, so the encoding is also part of what needs
to be described.
Dave Longley: That sounds like microformats which i'm -1 to
Christopher Allen: Not that concerned about value. Could be up
to the app/crypto suite to support the value format
Dave Longley: I'm fine with the appsuite defining what to do, but
they wouldn't use "value" (i wouldn't think).
Christopher Allen: Really would like to have an idea of the
application purpose - how many of them are there? How many can
support the values we would be using? Both for the CRUD of DID
docs and also for verifiable claims
Dave Longley: I'm interested in what nathan has to say about
application vs. key-intent ... i think we're conflating things a
bit and i'm not sure where everyone is.
Mike Lodder: Sounds like we don't want to do Option #A or option
#B? Should we take those off the list?
Nathan George: Application suite implies that we know in advance
what the applications are, and that might not be the case
Dave Longley: +1 To nathan, "application" is an ambiguous term i
think, in this discussion.
Dave Longley: And application in the way nathan means -- should
be defined by relation (or an application class should be defined
by relation), it isn't part of the key type.
Drummond Reed: Nathan said that its not so much application suite
- because that's not a fixed list - developers can "use or abuse"
any key for anything they want. So intent of usage is imporant.
Dave Longley: But that's separate from "key intent", etc.
Nathan George: Don't think we have the ability to enforce the
usage of keys for specific applications
Mike Lodder: +1 Drummond for key specs and intent
Dave Longley: The Crypto suite defines the crypto guarantees,
but I think we are trying to express is some additional
"recommended criteria for selecting this key for your use-case"
[scribe assist by Nathan George]
Drummond Reed: Let's use the mailing list as much as we can.
Nathan George: Which is fine by me -- i just don't want
extremely specific applications to bleed into the key type.
[scribe assist by Dave Longley]
Drummond Reed: We still need to discuss service descriptions and
Sam's HD metadata stuff
Dave Longley: YahooSignInKey
Christopher Allen: Gotta run. Ciao!
Dave Longley: We're on the same page there, and when someone
says "applicationsuite" I'm afraid of types like
"PlatformX_DoItExactkyMyWayForAuthentication" types [scribe
assist by Nathan George]
Dave Longley: Yup
Dave Longley: -1 To that.
Received on Thursday, 14 December 2017 20:00:09 UTC