07:26:53 <RRSAgent> RRSAgent has joined #did
07:26:53 <RRSAgent> logging to https://www.w3.org/2020/01/31-did-irc
07:26:55 <Zakim> RRSAgent, make logs Public
07:26:57 <Zakim> please title this meeting ("meeting: ..."), ivan
07:27:01 <burn> present+
07:27:15 <Identitywoman> Identitywoman has joined #did
07:27:45 <ivan> Meeting: DID Working Group F2F — 3rd day
07:27:56 <nicole> nicole has joined #did
07:28:03 <ivan> Agenda: https://tinyurl.com/didwg-ams2020-agenda
07:28:10 <ivan> Chair: burn, brent
07:28:25 <ivan> Meeting slides: https://tinyurl.com/didwg-ams2020-slides
07:28:29 <ivan> present+
07:28:34 <identitywoman_> identitywoman_ has joined #did
07:29:50 <identitywoman_> identitywoman_: practicing what they said
07:30:08 <yofukami> yofukami has joined #did
07:30:15 <identitywoman_> ... more practicing
07:30:27 <gannan> present+
07:30:59 <identitywoman_> @@@ someone is speaking
07:31:19 <identitywoman_> @@@: someone is speaking
07:32:03 <identitywoman_> s/@@@/identitywoman_
07:33:32 <yofukami> yofukami has joined #did
07:34:59 <yoshiaki> yoshiaki has joined #did
07:36:54 <ewelton> ewelton has joined #did
07:36:57 <ewelton> present+
07:37:20 <yoshiaki> present+
07:41:15 <brent> brent has joined #did
07:41:34 <brent> audio and slides: https://zoom.us/j/5593214233
07:42:52 <Joachim> Joachim has joined #did
07:43:04 <identitywoman> identitywoman has joined #DID
07:43:40 <brent> present+
07:43:44 <identitywoman> scribe+
07:43:47 <identitywoman> present+
07:43:52 <Joachim> present+
07:43:55 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
07:44:04 <Eugeniu_Rusu> present+
07:44:28 <Justin_R> Justin_R has joined #did
07:44:28 <manu> present+
07:44:42 <dezell> dezell has joined #did
07:44:42 <Justin_R> present+
07:44:45 <markus_sabadello> markus_sabadello has joined #did
07:44:55 <dezell> present+
07:44:56 <ken> ken has joined #did
07:45:04 <markus_sabadello> present+
07:45:06 <ken> present+
07:45:14 <charles> charles has joined #did
07:45:15 <tplooker> tplooker has joined #did
07:45:18 <tplooker> present+
07:45:23 <charles> present+
07:45:53 <gannan_> gannan_ has joined #did
07:46:05 <SamSmith> SamSmith has joined #did
07:46:19 <identitywoman> brent: outlining agenda
07:46:42 <selfissued> selfissued has joined #did
07:46:44 <selfissued> present+
07:49:38 <nicole> ok
07:51:23 <brent> Nicole, if you could introduce yourself here that would be great
07:51:40 <identitywoman> burn: the last day  of a face to face meeting
07:51:53 <identitywoman> ... does anyone need to leave early - yes after use-cases
07:52:36 <identitywoman> ... everyone knows it is the last day so we are going o talk about interesting
07:53:09 <identitywoman> ... thanks Kaliya for scribing
07:53:28 <drummond> drummond has joined #did
07:53:30 <drummond> present+
07:53:32 <identitywoman> ... we are not expecting that intense focus
07:53:42 <identitywoman> ... hopefully it will be a little more open and calmer
07:53:56 <nicole> I am from the China Academy of Information and Communications Technology.
07:54:18 <identitywoman> ivan: asked about boat tour feedback
07:55:07 <burn> Topic: Matrix Parameters
07:55:19 <identitywoman> @@@: Nicole is a
07:55:30 <identitywoman> slide 148 matrix paramter
07:55:41 <nicole> My chinese name is zhangyuwen
07:56:06 <burn> welcome zhangyuwen we are happy you are here!
07:56:10 <identitywoman> markus_sabadello: matrix parameter is not used that much in the specification it is called DID parameter.
07:56:10 <nicole> thanks
07:56:25 <identitywoman> ... TBL had this idea long ago
07:56:42 <identitywoman> ... I will share how we have them (wasn't my idea)
07:57:21 <identitywoman> ... in order to explain would like us to think of DIDs as a new building block for the web itself - we tend to think of it as something we need for some use-case, address for VCs, a look up key for a didComm session.
07:57:31 <identitywoman> ... lets think of it as a new type of address for web itself.
07:57:58 <identitywoman> ... we need a public key and service end point and not much else
07:58:25 <identitywoman> ... I could have many services in my did document - it is a URL and it could link a list of services to another URL not all necessarily tightly integrated with other features of the DID.
07:58:33 <identitywoman> ... I could use my did document as a set of slides
07:58:38 <identitywoman> ... slide 152
07:58:45 <identitywoman> (earlier we were on slide 151).
07:59:05 <identitywoman> ... it is an index of things social network service
07:59:10 <identitywoman> slide 153
07:59:22 <manu> q+ to note that services in a DID Document is probably an anti-pattern
07:59:37 <ivan> present+ nicole
07:59:40 <identitywoman> ... web linking - one url linking to other URLs is a fundamental feature of web ... number of ways to implement
07:59:47 <identitywoman> ... not only used for technical links
08:00:11 <identitywoman> ... in Indieweb it is a personal identifier - linking to micro sites and other profiles.
08:00:12 <manu> q+ to note that architecturally, matrix parameters are good/clean -- but don't think they're going to make it, may need to use something more hacky-like query params on DID identifier.
08:00:20 <identitywoman> ... this has nothing to do with LinkedData or RDF
08:00:28 <identitywoman> slide 154
08:01:06 <identitywoman> ... lets look at another feature - PURLs - persistant URL that doesn't change but the place it points to will point at
08:01:44 <identitywoman> ... people invented need because wanted location independent. have been criticized because  They are still tied to a network location.
08:01:48 <identitywoman> Slide 155
08:02:19 <identitywoman> ... there is also a feature called partial rediction - add path query or
08:02:33 <identitywoman> ... that path "stays"
08:02:48 <identitywoman> ... it will be added to the redirected URL
08:03:12 <identitywoman> ... information space is now included in
08:03:17 <identitywoman> ... what does htis remind of us
08:03:41 <identitywoman> ... DIDs are very much like this if I have a DID and de-reference to DIDComm, etc.
08:04:02 <identitywoman> ... traditional purls are persistant because of agreements
08:04:17 <identitywoman> ... with DID persistance is garanteed with cryptography and root of turs
08:04:21 <identitywoman> ...trust
08:04:31 <identitywoman> slide 157
08:04:48 <SamSmith> q
08:04:48 <ivan> q+ to get back to the structure of DID components
08:04:58 <SamSmith> q+
08:04:58 <identitywoman> ... you can add path query and redirection
08:05:07 <identitywoman> slide 158
08:05:34 <identitywoman> ... difference with DIDs.... DIDs support linking to different services...
08:05:41 <burn> q?
08:06:22 <identitywoman> ... as part of the innovation we couldn't use existing way to do this.
08:06:46 <identitywoman> ... initial idea to use semi-colen to add this extension
08:07:24 <identitywoman> burn: clarifying questions
08:07:30 <identitywoman> ivan: later
08:07:31 <burn> ack SamSmith
08:08:18 <identitywoman> SamSmith: I think a dynamic DNS like a Purl dynamically resolvable stable identifier - redirects whole name space.
08:08:37 <identitywoman> markus_sabadello:
08:08:56 <identitywoman> slide 159
08:09:02 <identitywoman> ... example of how this would work
08:09:09 <identitywoman> ... here it is already a matrix parameter
08:09:23 <identitywoman> ... instead of adding : and then a service.
08:09:28 <drummond> q?
08:09:38 <identitywoman> ... start with did URL
08:10:25 <identitywoman> ... it gives you portability - stable identifier that is independent of network address
08:10:42 <identitywoman> tplooker: clarifying question
08:10:58 <identitywoman> markus_sabadello: DID X
08:11:23 <identitywoman> markus_sabadello: slide 160 to summarize it combines features of two very interesting concepts in web architecture
08:11:45 <identitywoman> markus_sabadello: gives us all the features that did provides, cryptographic verifiablility, root of trust,
08:12:04 <identitywoman> markus_sabadello: on personal Self-sovereign name space that gives another web address that you want
08:12:15 <identitywoman> markus_sabadello: to compare this with quiry parameters
08:12:35 <burn> q+ to remind people that URL redirection in DIDs was an added feature and not in the original idea; but VERY VERY useful
08:12:52 <identitywoman> markus_sabadello: the queary parameters pass parameters into the DID resolution process
08:13:12 <identitywoman> markus_sabadello: just like the HTTP specificaiton doesn't tell you want to do with paths quieries and fragments
08:13:50 <identitywoman> markus_sabadello: like dynamic DNS - urn resolution - R components, q components f components
08:14:08 <identitywoman> markus_sabadello: do you want to use a resoluver in the Uk (on slide 162)
08:14:42 <identitywoman> markus_sabadello: the different quiry components are added to URL
08:15:04 <identitywoman> markus_sabadello: this is where we came up with this - we wanted a way to select the service. other parameters
08:15:27 <identitywoman> markus_sabadello: version ID and Version time if you don't wnat to resolve the current did document - version 4 or two months ago
08:15:42 <identitywoman> markus_sabadello: you might have a VC from earlier and want an older key
08:16:01 <identitywoman> markus_sabadello: want a version of the did document path quiry and fragment
08:16:09 <identitywoman> slide 163
08:16:18 <yoshiaki> s/wnat/what/
08:16:32 <identitywoman> slide 164
08:16:57 <burn> q+ to remind people that fragment processing is logically local and thus independent of DID method
08:17:16 <identitywoman> ... similar to - hash value - separate value - hashlinks is part of CCG work again
08:17:29 <identitywoman> markus_sabadello: some otehr matrix parameters that have been proposed over time
08:17:41 <identitywoman> markus_sabadello: I think we need a registry for this...
08:18:01 <identitywoman> slide 165 has the potential matrix parameters
08:18:19 <SamSmith> q+ "Invert the DNS resolution model thin layers"
08:18:25 <SamSmith> q
08:18:27 <identitywoman> ... input options into a resolver - things you pass separately from the URL
08:18:41 <drummond> q?
08:19:05 <identitywoman> markus_sabadello: during dereferencing passes things not all input options have to represented as matrix parameters (did parameters) are part of the URL.
08:19:26 <identitywoman> ... other things you don't want that are part of the URL
08:19:31 <SamSmith> q
08:19:32 <identitywoman> slide 166
08:19:37 <SamSmith> q+
08:19:38 <manu> q+ to note that adding a matrix parameter may change the resource being identified (in some cases it does, in others it doesn't)
08:19:41 <SamSmith> q
08:19:56 <identitywoman> ... summary of the issues  - not part of the standard URI parsers
08:20:32 <identitywoman> ... rejected 2 could be  parsed with standard URI parser
08:21:01 <identitywoman> ... entire authority component is non-standard... you have to have some parsing that is custom for the colons.
08:21:15 <identitywoman> ... I think you can say it is standard anyway or non-standard anyways
08:21:28 <identitywoman> ... it is to complex
08:21:44 <identitywoman> ... it does add complexity - no question - but is it worth it
08:21:51 <manu> q+ to strongly support the use case.
08:21:59 <identitywoman> ... optional? do we not want it all.
08:22:14 <identitywoman> ... it is a very old proposal it has not been used in http URL
08:22:16 <tplooker> q+
08:22:39 <identitywoman> ... we shouldn't reject because we haven't really seen them widespread use in URL
08:22:56 <manu> q+ to propose reserving the matrix params in the ABNF
08:23:13 <JoeAndrieu> JoeAndrieu has joined #did
08:23:14 <identitywoman> ... should we use existing "special query parameters"
08:23:40 <burn> qL
08:23:42 <burn> q?
08:23:42 <identitywoman> ... mentions different existing issues
08:23:47 <burn> ack man
08:23:47 <Zakim> manu, you wanted to note that services in a DID Document is probably an anti-pattern and to note that architecturally, matrix parameters are good/clean -- but don't think they're
08:23:50 <Zakim> ... going to make it, may need to use something more hacky-like query params on DID identifier. and to note that adding a matrix parameter may change the resource being identified
08:23:50 <Zakim> ... (in some cases it does, in others it doesn't) and to strongly support the use case. and to propose reserving the matrix params in the ABNF
08:23:53 <JoeAndrieu> present+ to ask about headers v URL parameters AND what are these NECESSARY for?
08:24:18 <identitywoman> manu: putting services in a did document might be an anti-pattern. don't know if we have raised an issue about this.
08:24:26 <identitywoman> ... not to say services are not useful - they are
08:24:34 <identitywoman> ... talking aobut use case and then solution to use-case
08:24:51 <identitywoman> ... use case is solid - concern that I have has to do with the solution
08:25:05 <identitywoman> ... if I had to hold my nose I could live with them in
08:25:10 <identitywoman> ... quesiton is there something simpler
08:25:26 <identitywoman> ... is there any objections to the use-case then it is a question of how we achive
08:25:29 <manu> zakim, who is here?
08:25:29 <Zakim> Present: burn, ivan, gannan, ewelton, yoshiaki, brent, identitywoman, Joachim, Eugeniu_Rusu, manu, Justin_R, dezell, markus_sabadello, ken, tplooker, charles, selfissued, drummond,
08:25:33 <Zakim> ... nicole, to, ask, about, headers, v, URL, parameters, AND, what, are, these, NECESSARY, for?
08:25:33 <Zakim> On IRC I see JoeAndrieu, drummond, selfissued, SamSmith, gannan_, tplooker, charles, ken, markus_sabadello, dezell, Justin_R, Eugeniu_Rusu, identitywoman, Joachim, brent, ewelton,
08:25:33 <Zakim> ... yoshiaki, yofukami, nicole, RRSAgent, Zakim, ivan, presenter, burn, llorllale, SteveTodd, wayne, deiu, rhiaro, ChristopherA, bigbluehat, jfishback, Travis, hadleybeeman, dlehn,
08:25:35 <Zakim> ... manu, dlongley, yancy
08:25:43 <yancy> present+
08:25:49 <JoeAndrieu> present+
08:25:53 <manu> present- to
08:25:55 <manu> present- ask
08:25:57 <burn> q?
08:25:57 <drummond> present+
08:25:59 <JoeAndrieu> q+  to ask about headers v URL parameters AND what are these NECESSARY for?
08:26:00 <manu> present- about
08:26:02 <burn> ack ivan
08:26:02 <Zakim> ivan, you wanted to get back to the structure of DID components
08:26:04 <manu> present- headers
08:26:08 <manu> present- v
08:26:09 <ewelton> q+ to comment on Manu's question about the nature of the use case here vs. IoT
08:26:12 <manu> present- URL
08:26:14 <identitywoman> ivan: i don't want to get into standards/nonstandards - that is a minor point
08:26:17 <Carsten> Carsten has joined #did
08:26:18 <manu> present- parameters
08:26:20 <manu> present- AND
08:26:24 <manu> present- what
08:26:27 <manu> present- are
08:26:29 <manu> present- these
08:26:30 <identitywoman> ... but I would step back a little bit - stand back look at DID uri structure as it is today
08:26:33 <manu> present- NECESSARY
08:26:40 <manu> present- for?
08:26:46 <drummond> q+
08:26:55 <identitywoman> ... my understanding is I and any of these goodies - then it is a differnet DID for a subject...all the security and keys are invalid for that URI
08:26:57 <manu> zakim, who is here?
08:26:57 <Zakim> Present: burn, ivan, gannan, ewelton, yoshiaki, brent, identitywoman, Joachim, Eugeniu_Rusu, manu, Justin_R, dezell, markus_sabadello, ken, tplooker, charles, selfissued, drummond,
08:27:01 <Zakim> ... nicole, yancy, JoeAndrieu
08:27:01 <Zakim> On IRC I see Carsten, JoeAndrieu, drummond, selfissued, SamSmith, gannan_, tplooker, charles, ken, markus_sabadello, dezell, Justin_R, Eugeniu_Rusu, identitywoman, Joachim, brent,
08:27:01 <Zakim> ... ewelton, yoshiaki, yofukami, nicole, RRSAgent, Zakim, ivan, presenter, burn, llorllale, SteveTodd, wayne, deiu, rhiaro, ChristopherA, bigbluehat, jfishback, Travis,
08:27:01 <Zakim> ... hadleybeeman, dlehn, manu, dlongley, yancy
08:27:31 <identitywoman> ... haven't found things in document - keys valid? problem with any additional structure - then is something to answer
08:27:39 <burn> q?
08:27:46 <manu> rrsagent, draft minutes
08:27:46 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html manu
08:28:01 <manu> rrsagent, make logs public
08:28:03 <identitywoman> ... what happens with URI and http - URI specification and is very vague pass fragment query means
08:28:06 <manu> rrsagent, draft minutes
08:28:06 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html manu
08:28:24 <burn> s/pass fragment/path fragment/
08:28:49 <identitywoman> ... reference to json, json-ld, cbor then don't know what fagments really mean. query paramter in URI work anyway we want.
08:29:07 <burn> q?
08:29:12 <burn> ack burn
08:29:12 <Zakim> burn, you wanted to remind people that URL redirection in DIDs was an added feature and not in the original idea; but VERY VERY useful and to remind people that fragment processing
08:29:15 <Zakim> ... is logically local and thus independent of DID method
08:29:19 <identitywoman> ... have the feeling of getting into the details one component - I'm not sure we have a through understanding of tehse components in the first place
08:29:38 <ivan> s/tehse/these/
08:29:46 <identitywoman> burn: these are sort of an added feature - they are very useful
08:30:04 <identitywoman> ... fragment processing is done - logically a local thing
08:30:16 <identitywoman> ... not something that DID methods get to mess with
08:30:25 <burn> q?
08:30:25 <markus_sabadello> q+
08:30:27 <burn> ack SamSmith
08:30:39 <identitywoman> ... DID methods don't get to define what happpens to fragment s(if we are in alignment with uRIs)
08:31:00 <identitywoman> ... could go straight to IPv6 static
08:31:21 <identitywoman> ... disrupt DNS zero trust
08:31:38 <identitywoman> ... establish control authority - fixing the whole in DNS by doing it this way
08:32:01 <burn> ack tplooker
08:32:01 <identitywoman> ... layering - control authority, then indirection
08:32:08 <selfissued> q+
08:32:36 <identitywoman> tplooker: if we are using DID URL and different did of different schemes did URI - to URL and define behavior and de-referencing.
08:32:39 <drummond> q?
08:32:51 <identitywoman> tplooker: if you dereference and don't know how to respond
08:32:56 <manu> q+
08:33:04 <identitywoman> markus_sabadello: now did resolution specification dfines waht you do with the parameters.
08:33:42 <burn> ack JoeAndrieu
08:33:42 <Zakim> JoeAndrieu, you wanted to ask about headers v URL parameters AND what are these NECESSARY for?
08:33:48 <identitywoman> markus_sabadello: a way we can simplfy this - how relative URIs work - take what is in DID URL - apply existing relative URI - relative to the service end point - don't have to invent anything new
08:33:52 <selfissued> q+
08:34:05 <identitywoman> JoeAndrieu: confused between difference between service parameters and matrix end points.
08:34:14 <identitywoman> JoeAndrieu: not defined in the use-cases document.
08:34:32 <identitywoman> JoeAndrieu: what was maintaining the entire path and query
08:34:55 <identitywoman> JoeAndrieu: in we re-direction doesn't maintain ???
08:35:20 <burn> ack ewelton
08:35:20 <Zakim> ewelton, you wanted to comment on Manu's question about the nature of the use case here vs. IoT
08:35:22 <identitywoman> JoeAndrieu: conflating URL - header with this
08:35:44 <identitywoman> ewelton: see as potential to maintain persistance
08:35:55 <identitywoman> ewelton: there needs to be all kind of extensibility
08:36:11 <burn> ack drummond
08:36:12 <identitywoman> ewelton: that is divorced from trust/control thing are they appropriate use-cases in did core spec
08:36:36 <identitywoman> drummond: to ivans point the DID itself - always identifies the DID subject
08:37:06 <identitywoman> drummond: DID is a uri
08:37:21 <identitywoman> drummond: anything beyond that we call a "did url"
08:38:02 <JoeAndrieu> q+ to talk about authority component
08:38:15 <burn> ack markus_sabadello
08:38:16 <identitywoman> drummond: the components in 3986 are bery clear there - DID are a new type of authority component. single strongest reason to put as part of authority component
08:38:57 <ivan> q+
08:39:02 <identitywoman> markus_sabadello: also wanted to comment on what Ivan said - does create a new identiifer - doesn't mean the did subject changes. perfectly fine to have multiple different identifiers that point to same individuals.
08:39:03 <drummond> q+
08:39:16 <identitywoman> markus_sabadello: agree only authority component we can control.
08:39:26 <identitywoman> markus_sabadello: we could control the query
08:39:32 <ewelton> q+ to comment I love the idea that a DID Url is "based on the DID" and thus ties into a 2nd class of information (beyond authority/trust control) which has fundamentally different characteristics in terms of extensibility, resolution, query-parameters, matrix parameters, encoding, etc. - all which is *not needed* by class of use-cases while being essential for a different class.
08:39:43 <identitywoman> markus_sabadello: paramters - we could do it. don't think we should do it.
08:40:03 <identitywoman> markus_sabadello: leave it undefined for method developers - concrete exmple of why it could not work.
08:40:13 <identitywoman> markus_sabadello: could only go through matrix paramters
08:40:15 <burn> ack selfissued
08:40:16 <brent> q?
08:40:24 <manu> q+ to propose reserving matrix params
08:40:30 <identitywoman> markus_sabadello: agree with manu shoudl ask if we want to support use-cases
08:40:57 <identitywoman> selfissued: missed a bit
08:41:00 <gannan> gannan has joined #did
08:41:16 <markus_sabadello> q+
08:41:36 <identitywoman> selfissued: when used with oauth has particular meaning - establish a registry with quiry parmeters that are used with DIDs so common understanding thus not
08:41:58 <selfissued> https://tools.ietf.org/html/rfc6750 is an example of a spec defining a query parameter: access_token
08:42:06 <burn> ack manu
08:42:06 <Zakim> manu, you wanted to propose reserving matrix params
08:42:20 <identitywoman> manu: so not hearing - not a valid use case
08:42:31 <gannan> gannan has joined #did
08:42:35 <selfissued> We should establish a registry for query parameters used with DIDs, per our decisions yesterday
08:42:42 <identitywoman> JoeAndrieu: can't comment on use case I don't understand
08:42:56 <identitywoman> manu: paths - are a good use case - please disagree?
08:42:57 <selfissued> Then we are facilitating use of query parameters with DIDs in an interoperable way
08:42:58 <burn> q?
08:43:13 <identitywoman> manu: if no one disagrees - discussion about how we achived
08:43:30 <SamSmith> q+
08:43:36 <identitywoman> manu: would like to understand markus opinion better
08:43:45 <burn> ack JoeAndrieu
08:43:45 <Zakim> JoeAndrieu, you wanted to talk about authority component
08:43:46 <selfissued> q+
08:44:07 <manu> q+ to speak to value to users for redirection.
08:44:12 <identitywoman> JoeAndrieu: paths is not a use-case doesn't tell me the value for the end user and why paths create that value - woudn't it be nice ot have it
08:44:26 <identitywoman> JoeAndrieu: other then drop-box use case that hasn't been written up
08:44:31 <JoeAndrieu> 3.2.  Authority : Many URI schemes include a hierarchical element for a naming authority so that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further).
08:44:49 <identitywoman> JoeAndrieu: we are mis-speacking about authority in DID.  method is the authority
08:44:56 <burn> q+ to correct people on authority claims
08:45:09 <burn> ack ivan
08:45:15 <identitywoman> ... when you go look up the method - that is the authority part... if we want to undersatnd how we fit in standard parsers
08:45:27 <identitywoman> ivan: didn't understand what drummond is saying
08:46:12 <identitywoman> ivan: the fact I can be identified by several DID - this is obvious - i don't know DID..method...blahblah blah... semicolen - who is subject of "that" did. cause it is differnet DID with
08:46:18 <brent> q+ to clarify the difference between a did and a didurl
08:46:30 <Justin_R> Justin_R has joined #did
08:46:40 <burn> ack drummond
08:46:43 <identitywoman> ... in semantic web they are very sensitive...about all syntax we have to answer this question
08:47:01 <identitywoman> drummond: to joes point - authority portion..heirpart
08:47:06 <oliver> oliver has joined #did
08:47:14 <oliver> present+ oliver
08:47:31 <brent> q-
08:47:58 <identitywoman> drummond: in ABNF in our current spec - does n't refer to anything beyond did:namespace: method specfiic ID (single charracter beyond) then it is DID URL - then you are identifiying another resource - may or may not be subject
08:48:07 <burn> ack ewelton
08:48:07 <Zakim> ewelton, you wanted to comment I love the idea that a DID Url is "based on the DID" and thus ties into a 2nd class of information (beyond authority/trust control) which has
08:48:10 <Zakim> ... fundamentally different characteristics in terms of extensibility, resolution, query-parameters, matrix parameters, encoding, etc. - all which is *not needed* by class of
08:48:10 <Zakim> ... use-cases while being essential for a different class.
08:48:10 <identitywoman> ivan: it isnt in the document - it is the ABNF
08:48:14 <burn> q?
08:48:34 <identitywoman> ewelton: like what drummond said - brings a 2nd class of use
08:48:45 <identitywoman> ewelton: is it a CORE part of DID
08:48:54 <drummond> q+
08:49:07 <identitywoman> ewelton: concern about location of use-cases in this
08:49:13 <burn> ack markus_sabadello
08:49:20 <identitywoman> ewelton: don't take as substantive
08:49:38 <burn> q?
08:49:44 <identitywoman> markus_sabadello: not clearly specify what that identifier is
08:50:07 <identitywoman> markus_sabadello: would have to specify
08:50:23 <drummond> The reference I made in my remark is in RFC 3986, The URI Specification, Appendix A, first line: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
08:50:24 <JoeAndrieu> q+ about path part ambiguity
08:50:27 <identitywoman> markus_sabadello: re what mike manu raised special use-cases
08:50:32 <JoeAndrieu> q+ to about path part ambiguity
08:50:34 <drummond> q?
08:50:49 <burn> zakim, close the queue
08:50:49 <Zakim> ok, burn, the speaker queue is closed
08:51:01 <markus_sabadello> present+
08:51:05 <burn> q?
08:51:07 <burn> ack selfissued m
08:51:15 <burn> ack SamSmith
08:51:43 <chaals> chaals has joined #did
08:51:58 <identitywoman> SamSmith: would ask group to step back on this topic - why we are here current security model is broken - how do we fix the security model of the web - we have opporutnity - address problems web has
08:51:59 <burn> ack selfissued
08:52:02 <burn> ack manu
08:52:02 <Zakim> manu, you wanted to speak to value to users for redirection.
08:52:23 <identitywoman> manu: I feel like we are hvaing two totlaly different discussions - most people trying to sovle the use- case but isn't clearly defined
08:53:20 <drummond> q?
08:53:24 <identitywoman> manu: can we just talk about teh use-cases
08:53:33 <identitywoman> manu: there is one the look up use-case
08:53:52 <identitywoman> slide 169 says do this use-case with
08:54:12 <identitywoman> burn: we will finish que and then define use case
08:54:13 <burn> ack burn
08:54:13 <Zakim> burn, you wanted to correct people on authority claims
08:54:44 <Juan_caballero> Juan_caballero has joined #did
08:54:44 <identitywoman> burn: the authority part of the URI - joe you said it said something and the text disagrees
08:54:49 <ivan> s/hvaing/having/
08:54:55 <Juan_caballero> Present+
08:55:04 <identitywoman> burn: many schemes will - will come up with an authority part that does these things
08:55:06 <ivan> s/totlaly/totally/
08:55:22 <burn> q?
08:55:25 <burn> ack drummond
08:55:28 <identitywoman> burn: we may have done that via the did method - the URI does n't say there must be an authority part of a URI
08:55:39 <SamSmith> q+
08:55:41 <identitywoman> drummond: it is the first line of the speck
08:55:51 <identitywoman> drummond: hierpart - is required
08:56:08 <identitywoman> drummond: is an optional part - the authority part
08:56:12 <ivan> s/speck/spec/
08:56:50 <burn> ack JoeAndrieu
08:56:50 <Zakim> JoeAndrieu, you wanted to about path part ambiguity
08:56:50 <identitywoman> drummond: when it comes to use-cases services and service indirection - we have many other did parameters we have been talking about. The sovrin community we must have versioning of DID documents and consistant way of doing it and it can't be in the fragment  - if quiry parameters.
08:57:16 <identitywoman> JoeAndrieu: so to respond to dan's comment - didn't say we hvae to have an authority component and the hierarchicla is method and pethod specific identifier
08:57:27 <burn> q?
08:57:47 <identitywoman> JoeAndrieu: I believe we have an authority part that isn't named in teh spec. one of the issues with the us-case the path fit withouth a service end point there is no concensus
08:58:27 <identitywoman> ... the current proposed rule is that path quiry part and path - doesn't work (not sure exactly.. )
08:58:43 <burn> zakim, open the queue
08:58:43 <Zakim> ok, burn, the speaker queue is open
08:58:44 <markus_sabadello> q+
08:58:48 <ivan> Topic: use cases
08:59:07 <JoeAndrieu> q+
08:59:08 <tplooker> q+
08:59:10 <Carsten> q+
08:59:12 <drummond> q+
08:59:13 <ivan> s/Topic:/Subtopic/
08:59:16 <identitywoman> que about use-cases
08:59:19 <burn> ack markus_sabadello
08:59:33 <identitywoman> markus_sabadello: use-cases NOt mechanism parameters - slide 159
08:59:44 <identitywoman> ... persistant web address
08:59:59 <SamSmith> q+   persistent identifier of indictable service endpoint
09:00:26 <SamSmith> q+ to persistent identifier of indirectable service endpoint IP address
09:00:44 <burn> ack JoeAndrieu
09:00:45 <identitywoman> markus_sabadello: points at the first part of the resume section - move file to hosted service to self-hosted service don't have t update the document. quirey and matrix don't get cancotenated -
09:00:52 <identitywoman> JoeAndrieu: i call this the drop-box use case
09:00:52 <markus_sabadello> q+
09:00:59 <markus_sabadello> q-
09:01:01 <manu> q+ we're done w/ use cases - let's move on to addressing the use case.
09:01:02 <identitywoman> use-case slide 169
09:01:16 <ken> q+
09:01:20 <identitywoman> JoeAndrieu: usecase name "movable "dropbox""
09:01:42 <manu> q+ to say we can be done w/ use cases - let's move on to addressing the use case.
09:01:49 <markus_sabadello> q+
09:01:52 <identitywoman> JoeAndrieu: key thing about this use-case is that you want to be able to append a long path and move the route around
09:02:33 <identitywoman> JoeAndrieu: i can have a service for my business card... if you want a complicated path structure maintained. go to my did and get the avatar...
09:03:04 <burn> ack tplooker
09:03:05 <identitywoman> JoeAndrieu: my understanding is that you want to be able to move it - you can't predict the future endpoint in the future - don't htink it works it britta
09:03:12 <manu> q- later
09:03:20 <identitywoman> tplooker: bootstraping communication with did subjects
09:03:52 <identitywoman> tplooker: start with DID and VC rendered human friendly information
09:04:09 <manu> q+ to say that "discovery mechanism" can already be done w/ service descriptions.
09:04:17 <burn> ack Carsten
09:05:00 <identitywoman> Carsten: IoT data streaming - work sam has done - i can give data stream - within that hash service
09:05:19 <manu> q+ to agree w/ Joe - I'm not hearing other use cases - or other use cases sound just like Linked Data.
09:05:44 <burn> ack drummond
09:05:47 <identitywoman> Carsten: did for entire data stream - every data within is hash - then can reference within the stream
09:06:23 <identitywoman> drummond: joes concern about possible brittleness DID based URL
09:06:52 <identitywoman> drummond: use-case for portable files systems or data hierarchy if we support this use-case for data portabiliyt in general and data authority - did based data portability
09:07:07 <ewelton> q+ to suggest mapping webs of crypto material expressing relationships between actors in personal, self-sovereign (none of your business), trust arrangements
09:07:09 <identitywoman> drummond: DID BASED DATA PORTABILITY
09:07:13 <burn> ack SamSmith
09:07:13 <Zakim> SamSmith, you wanted to persistent identifier of indirectable service endpoint IP address
09:08:16 <identitywoman> SamSmith: re-inforce what drummond said - persistant identiifer or an indirectable - the motivation is that the value that an identifier has in a social construct with respect of the user in contorl - user is in control.
09:08:36 <identitywoman> SamSmith: without this we haven't given people self-sovereign - control of their own data
09:08:36 <burn> ack ken
09:08:59 <identitywoman> ken: as verifer i might want to access a point in time - so can access
09:09:07 <burn> ack markus_sabadello
09:09:19 <identitywoman> markus_sabadello: respond to brittleness ?
09:09:32 <identitywoman> burn: looking for more use-cases
09:09:33 <burn> q+ markus_sabadello
09:09:38 <burn> ack manu
09:09:38 <Zakim> manu, you wanted to say we can be done w/ use cases - let's move on to addressing the use case. and to say that "discovery mechanism" can already be done w/ service descriptions.
09:09:40 <JoeAndrieu> q+
09:09:41 <Zakim> ... and to agree w/ Joe - I'm not hearing other use cases - or other use cases sound just like Linked Data.
09:10:02 <identitywoman> manu: I think we only have one use-case that can't be solved with mechanisms we have - did based portability so I think I agree with drummond, sam
09:10:18 <identitywoman> manu:  having a service in your did doucment can serve many of these in
09:10:36 <identitywoman> manu: iot - can be done with .. (didn't get)
09:10:50 <brent> q?
09:11:18 <identitywoman> manu: looks like we have to debate  - rest we have ways to solve
09:11:27 <gannan> gannan has joined #did
09:11:28 <burn> ack ewelton
09:11:28 <Zakim> ewelton, you wanted to suggest mapping webs of crypto material expressing relationships between actors in personal, self-sovereign (none of your business), trust arrangements
09:11:33 <oliver> q+
09:11:47 <ivan> present+ oliver
09:11:51 <identitywoman> ewelton: I think this is a use-case heard on did resolver calls - reaching into crypto material
09:12:19 <burn> ack JoeAndrieu
09:12:21 <identitywoman> ewelton: keys and key materials ... (missed)
09:12:36 <identitywoman> JoeAndrieu: data portability is hirerachy and incorporates data streaming
09:12:51 <identitywoman> JoeAndrieu: ken I don't understand value proposition
09:12:53 <burn> ack markus_sabadello
09:12:57 <ken> q+
09:13:04 <identitywoman> markus_sabadello: brittleness...response
09:13:17 <identitywoman> markus_sabadello: made another slide 160
09:14:23 <gannan> q+
09:14:27 <Justin_R> q+ to ask about common API patterns
09:14:32 <JoeAndrieu> q+ to suggest a fix that allows this use case without changes
09:14:34 <SamSmith> q+
09:14:47 <burn> zakim, close the queue
09:14:47 <Zakim> ok, burn, the speaker queue is closed
09:14:49 <identitywoman> markus_sabadello: now I understand the potential brittleness - withouth adding appending paths - if service type is the same ... hosted next cloud - changes location then it is the same
09:15:04 <identitywoman> markus_sabadello: then I want partial re-direction
09:15:08 <SamSmith> q+ to hierarchy
09:15:11 <burn> ack oliver
09:15:14 <drummond> q?
09:15:18 <Justin_R> q
09:15:25 <SamSmith> +1 joe hierarchic structure  portable hierarchy
09:15:32 <markus_sabadello> q+
09:15:43 <identitywoman> oliver: I while ago question on should we add transform keys matrix parameters ... I would like to be sure this use case is still possible.
09:15:49 <burn> ack ken
09:15:51 <identitywoman> oliver: use case that I see
09:16:22 <identitywoman> ken: benifit is to get the correct document at a particular point in time - valuable use-case so use
09:16:41 <identitywoman> JoeAndrieu: current did document is the authoritative one and what you are doing is something exceptional
09:17:20 <identitywoman> JoeAndrieu: less then 15 min less - no reslutions or decisions - was valuable...to engage with what are the use-cases people who disagree that these use-cases are sufficient to motivate those features
09:17:37 <ivan> Subtopic: discussion closure
09:18:14 <identitywoman> burn: who hear believes that there is at least one use-case there for them motivates the need for the matrix [did] parameters feature
09:18:42 <markus_sabadello> +1
09:18:42 <gannan> +1
09:18:45 <JoeAndrieu> -1
09:18:46 <manu> +1
09:18:46 <oliver> +1
09:18:46 <ken> +1
09:18:47 <yancy> -1
09:18:48 <drummond> +1
09:18:48 <SamSmith> +1
09:18:52 <selfissued> -1
09:18:56 <ivan> 0
09:18:57 <charles> +1
09:18:59 <Justin_R> 0
09:18:59 <Eugeniu_Rusu> -1
09:18:59 <Carsten> +1
09:19:00 <tplooker> +1
09:19:04 <dezell> 0
09:19:04 <brent> 0
09:19:05 <manu> For the record, I think there is only one use case
09:19:10 <Joachim> 0
09:19:32 <JoeAndrieu> q?
09:19:42 <markus_sabadello> Slide that explores if/how the PURL data portability use case can be achieved with query parameters: https://docs.google.com/presentation/d/1XI5rrEdBUSYd2tW07GfzOjBkvgKmfeKQyh95Ekl-u8o/edit#slide=id.g76bd51c181_28_12
09:19:42 <markus_sabadello> q+
09:20:12 <drummond> Can we have Markus present his slides?
09:20:17 <identitywoman> ivan: zero because there are other ways to solve
09:20:48 <ivan> present+ Eugeniu_Rusu
09:20:53 <ivan> s/there are/there may be/
09:21:34 <identitywoman> chairs confering
09:23:19 <identitywoman> use-cases that can't be solved in another way
09:23:36 <identitywoman> @@@: what are some other mechanisms that can solve it
09:24:02 <identitywoman> joe
09:24:02 <burn> s/@@@/brent/
09:24:08 <burn> q?
09:24:16 <identitywoman> JoeAndrieu: just had backchannel that clarified
09:24:36 <drummond> q?
09:25:30 <burn> ack gannan
09:25:35 <burn> ack Justin_R
09:25:35 <Zakim> Justin_R, you wanted to ask about common API patterns
09:25:37 <burn> ack JoeAndrieu
09:25:37 <Zakim> JoeAndrieu, you wanted to suggest a fix that allows this use case without changes
09:25:41 <burn> ack SamSmith
09:25:46 <identitywoman> JoeAndrieu: ealier touched on conflation between service end point parameters - didn't undersand they are merged into a single context
09:26:01 <identitywoman> JoeAndrieu: haven't heard any of tehse map into a matrix paramter that isn't a service use case
09:26:09 <identitywoman> ivan: (missed)
09:26:27 <identitywoman> @@@:
09:26:45 <burn> s/@@@/Justin_R/
09:26:48 <ivan> s/(missed)/there was also the 'hl' approach as an example
09:26:55 <burn> zakim, open the queue
09:26:55 <Zakim> ok, burn, the speaker queue is open
09:27:00 <identitywoman> @@@: my question to the group is - do we believe that having effectively stable APIs such that quiry and path parametrs will be portable across
09:27:34 <brent> q?
09:28:16 <yancy> s/quiry/query
09:29:02 <identitywoman> Justin_R: 160 - do we as a working group believe that there are going to be enough cases where I have a something like this -... one hose with a particular path ... replicated in same way...is it worth to carry through after the DID URL has been processed
09:29:14 <identitywoman> Drummond: would a portability of a blog?
09:29:34 <identitywoman> Justin_R: No blogs are totally different
09:30:02 <gannan> gannan has joined #did
09:30:10 <identitywoman> burn: we still end up needing the usecases that can't be solved in any other way - to get to that point the existing use-cases solved in any other way.
09:30:40 <identitywoman> burn: not going to happen at this meeting - two things are good next steps for us to do as this toic (eveyrone agrees)
09:30:50 <identitywoman> burn: who wants to lead an issue
09:31:23 <identitywoman> @@@: refining use-cases  AND how to solve without matrix parameters
09:31:41 <ivan> s/@@@/brent/
09:31:41 <identitywoman> Markus and Joe voluneer to pull documents together - when do you want it done by
09:32:20 <identitywoman> drummond sam and ken all volunteer - don't want to hear...no time to look at four months from now
09:32:36 <selfissued> q+
09:32:43 <identitywoman> JoeAndrieu: much of my argument is that it can be done via service end point - matrix parameter.
09:35:07 <burn> burn has joined #did
09:50:34 <ewelton> present+
09:50:35 <burn> burn has joined #did
09:51:08 <selfissued> selfissued has joined #did
09:51:17 <selfissued> present+
09:51:22 <ivan> present+ pamela
09:51:46 <ivan> scribe+ dezell
09:52:26 <gannan> gannan has joined #did
09:53:07 <ivan> Topic: spec structure
09:53:12 <tplooker> tplooker has joined #did
09:53:12 <oliver> oliver has joined #did
09:53:12 <ken> ken has joined #did
09:53:15 <oliver> present+ oliver
09:53:17 <tplooker> present+
09:54:00 <dezell> Drummond gives his presentation - Spec Structure
09:54:02 <ChristopherA> present+
09:54:06 <ChristopherA> q
09:54:06 <drummond> drummond has joined #did
09:55:22 <Justin_R> Justin_R has joined #did
09:55:39 <Justin_R> q
09:55:55 <Justin_R> q+ to talk about what top-level restructured concerns would be
09:56:33 <JoeAndrieu> q+
09:56:34 <manu> q+ to support new structure
09:56:36 <dezell> drummond: I have produced a "straw-man" to start discussion.
09:56:57 <dezell> drummond: does this exercise make sense?
09:57:05 <ivan> q+
09:57:33 <brent> ack selfissued
09:57:47 <dezell> mike: ABNF seems out of place.
09:57:54 <tplooker> q+
09:58:19 <oliver> q+
09:58:26 <dezell> drummond: I added ABNF to help identify the original section.
09:58:43 <dezell> q?
09:58:57 <brent> ack Justin_R
09:58:57 <Zakim> Justin_R, you wanted to talk about what top-level restructured concerns would be
09:58:58 <markus_sabadello> q+
09:59:01 <SamSmith> q+
09:59:26 <dezell> Justin_R: need to discuss "new structure" in the context of producers and consumers.
09:59:44 <oliver> q-
10:00:11 <dezell> ... also what does it mean (e.g.) when processing with JSON-LD.  What if there is no @context field?
10:00:29 <dezell> ... it will specific to each representation type.
10:00:39 <brent> ack JoeAndrieu
10:00:57 <dezell> JoeAndrieu:  we need to link back to the use cases.
10:01:04 <brent> q?
10:01:08 <Justin_R> -1 to adding use cases to the spec
10:01:18 <Justin_R> + 0.5 to motivations
10:02:11 <dezell> s/link back to/include/
10:02:26 <brent> ack manu
10:02:26 <Zakim> manu, you wanted to support new structure
10:02:44 <JoeAndrieu> +1 Justin_R This would be the distillation of requirements from the use case & requirements doc. not listing the use cases.
10:02:52 <dezell> manu: first time I've seen this new structure, but +1 (for either Proposal #1 or #2)
10:03:05 <dezell> ... also like "producer/consumer" idea.
10:03:11 <brent> ack ivan
10:03:55 <dezell> ivan: one problem with the current document - there is not one place where I can find the terms that are essential.
10:04:20 <dezell> ... "these are the terms this specification defines."  Probably goes into the abstract data model.
10:04:37 <dezell> brent: why is it different from the terminology section.
10:04:49 <dezell> s/section\./section\?/
10:05:05 <burn> q?
10:05:15 <brent> ack tplooker
10:05:22 <dezell> ivan: there should be one place for the definition.
10:05:59 <Justin_R> +q to argue for multiple documents
10:06:11 <JoeAndrieu> q+ to break out DID Documents (or whatever we are going to call it)
10:06:20 <burn> q+ to suggest adding "DID document" above 4-7
10:06:39 <oliver> +1
10:06:45 <dezell> tobias: (recommending a rework of the new structure).  terminology, syntax, datamodel
10:07:02 <dezell> ... should have this overarching flow.
10:07:09 <brent> ack markus_sabadello
10:07:41 <selfissued> q+
10:07:51 <dezell> markus_sabadello: I like the new structure.  There will be multiple extensibility models.  The term seems to imply there is only one model.
10:07:53 <oliver> q+
10:07:59 <Justin_R> +1 to mechanisms
10:08:01 <brent> ack SamSmith
10:08:41 <dezell> SamSmith: I think 4, 6, and 7 should be a new section "DID Documents".
10:09:13 <dezell> ... extensibility above abstract data model.
10:09:22 <pam> pam has joined #did
10:09:31 <dezell> ... then create a new section "Did Documents" and put 4, 6, and 7 under that.
10:09:46 <burn> q-
10:09:55 <brent> ack Justin_R
10:09:55 <Zakim> Justin_R, you wanted to argue for multiple documents
10:09:56 <tplooker> q+
10:09:56 <markus_sabadello> q+
10:10:12 <brent> ack JoeAndrieu
10:10:12 <Zakim> JoeAndrieu, you wanted to break out DID Documents (or whatever we are going to call it)
10:10:18 <dezell> Justin: a good first step, but we need to consider breaking into multiple documents.
10:10:21 <manu> q+ to argue against multiple documents.
10:10:24 <ivan> q+ to talk security/privacy placing; use of did document as a term
10:10:53 <ken> q+
10:11:00 <dezell> JoeAndrieu: We are missing the relationship between DID and DID Documents.  A section 3 for "overall architecture" would help clarify.
10:11:01 <brent> ack selfissued
10:11:16 <dezell> MikeJones:  I strongly object to the 's' at the end of mechanisms.
10:11:54 <dezell> ... we agreed to exactly one such mechanism for interoperability.  Private extensions not affected.
10:12:01 <brent> q?
10:12:16 <dezell> ... registries are the interoperable extension mechanism.
10:12:25 <Justin_R> +1
10:12:28 <manu> q+ to agree with Mike, but note that this is the crux of the debate.
10:12:30 <brent> ack oliver
10:12:34 <dezell> brent: how about just "extensibility"
10:12:42 <drummond> q+
10:12:46 <Justin_R> +1 to talk about abstraction order
10:12:52 <dezell> oliver: extensibility belongs under "DID Documents".
10:12:52 <Justin_R> +q to talk about abstraction order
10:13:13 <ivan> q
10:13:14 <Justin_R> s/+1 to talk about abstraction order//
10:13:18 <brent> ack tplooker
10:13:49 <dezell> tobias: extensibility comes to early in the list, before we define what we're extending.
10:13:54 <selfissued> I believe that the extensibility section should describe that we use registries to facilitate extensibility and not define or describe any other mechansims
10:14:00 <Justin_R> s/to early/too early/
10:14:02 <burn> q+ to suggest extensibility section right before security considerations which talks generically about it
10:14:12 <ken> +1 to Tobias comments on extensibility coming after the definition of the thing you are extending.
10:14:20 <ken> q-
10:14:21 <oliver> +1
10:14:27 <brent> ack markus_sabadello
10:14:30 <dezell> ... "extensibility" can appear under other topics in context.
10:15:17 <selfissued> q+
10:15:40 <dezell> markus_sabadello: it seems like a contradiction to say there's only one extensibility mechanism when we know there will be others.
10:15:57 <dezell> ... propose to add back the word that drummond just deleted.
10:16:05 <selfissued> So that we're clear, this section should also include this statement at the end "Other extensibility mechanisms MAY be used by particular organizations or communities but defining such mechansims is out of scope for this specification"
10:16:07 <ken> +1 to Markus suggestion that we define how extensibility works that may not be non-global.
10:16:55 <markus_sabadello> q+
10:17:04 <dezell> dan: the chairs believe from the conversation yesterday, people who what more extensibility mechanisms can do that.  We really don't want to restart that conversation.
10:17:50 <dezell> ... will anyone raise a formal objection?
10:18:06 <dezell> markus: I will object if other extensibility mechanisms are out of scope.
10:18:37 <dezell> dan: I'm asking whether the work "mechanisms" has to appear after "extensibility."
10:18:55 <drummond> q?
10:19:07 <dezell> (no responses)
10:19:27 <brent> ack manu
10:19:28 <Zakim> manu, you wanted to argue against multiple documents. and to agree with Mike, but note that this is the crux of the debate.
10:19:39 <dezell> manu: going back to Justin's comment about multiple documents.
10:19:50 <dezell> ... I'm a strong -1 for splitting up the spec.
10:20:03 <SamSmith> +1 Manu
10:20:18 <dezell> ... I hear tons of complaints resulting from splitting documents.
10:21:10 <dezell> ... (not reopening the extensibility debate) I think both sides have a point and we're proceeding in good faith that we'll come to consensus.
10:21:32 <drummond> q?
10:21:50 <brent> ack ivan
10:21:50 <Zakim> ivan, you wanted to talk security/privacy placing; use of did document as a term
10:22:17 <burn> -1 to moving sec and priv sections
10:22:27 <Justin_R> -1 to putting sec/priv forward
10:22:32 <dezell> ivan: normally "security" appears in the "privacy" section.  I think security and privacy should appear earlier in the document to give the required emphasis.
10:22:37 <SamSmith> Overall architecture should include security and privacy
10:22:38 <brent> ack drummond
10:22:43 <SamSmith> discussion
10:22:56 <dezell> ... especially for this topic.
10:23:39 <dezell> ... also, it's DID Information, "DID Document" gives the wrong impression.
10:23:49 <brent> -1 to moving priv and sec sections
10:23:52 <tplooker> q+
10:24:00 <brent> +1 to renaming DID Document
10:24:17 <gannan> +1
10:24:17 <Justin_R>  +1 to forward pointers (as is tradition)
10:24:30 <SamSmith> q+
10:24:33 <burn> q?
10:25:08 <burn> q
10:25:09 <dezell> drummond: the positioning of "extensibility" is difficult. I'd like to discuss extensibility in the context of the relevant topic.
10:25:19 <JoeAndrieu> +1 to inline extensibility
10:26:08 <dezell> dan: we're hoping not to be too prescriptive about where we can and can not talk about extensibility.
10:26:23 <dezell> ... at this point the topic is editorial.
10:26:28 <Justin_R> +1 to the chairs' point
10:27:02 <ken> +1
10:27:13 <dezell> ... suggest leaving "Extensibility" where it is, and leave it to editor discretion.
10:27:31 <dezell> ... we would like to move on (group agrees).
10:27:32 <drummond> q?
10:27:32 <brent> ack Justin_R
10:27:34 <Zakim> Justin_R, you wanted to talk about abstraction order
10:27:37 <drummond> q+
10:27:38 <burn> q-
10:28:20 <dezell> Justin_R: +1 to considering in-line extensibility.  In general, it's easier for people to read a document that goes from concrete to abstract than the other way around.
10:28:37 <Juan_caballero> Juan_caballero has joined #did
10:28:40 <manu> q+ for concrete example at the front of the spec.
10:29:03 <dezell> ... I ask the editors to keep in mind that people will be looking for concrete things first.
10:29:06 <brent> ack selfissued
10:29:07 <burn> q+
10:29:21 <Juan_caballero> +1 to Justin and Tobias' comments on prioritizing how most laypersons read specs
10:29:42 <Juan_caballero> Sorry, most implementers
10:29:55 <dezell> Mike: I never suggested that there be only one extensibility mechanism.
10:30:19 <burn> q?
10:30:20 <brent> q?
10:30:25 <dezell> ... what we >did< do was explain the "interoperable" mechanism that is in scope for the document.
10:30:25 <brent> ack markus_sabadello
10:30:47 <brent> ack tplooker
10:30:58 <ChristopherA> q+
10:31:05 <dezell> markus_sabadello: I think we still have disagreement about those alternatives being out of scope.
10:31:34 <Juan_caballero> +1 to tobias' proposal, slide 177
10:31:43 <ChristopherA> q+ to If the one extensibility data model doesn't allow methods to extend, I like Markus would formally object.
10:31:45 <drummond> +1
10:31:55 <brent> ack SamSmith
10:32:42 <dezell> SamSmith: (scribe missed - suggestions about adding more detail.)
10:33:02 <burn> q-
10:33:08 <manu> q+ to note that it's helpful to the editors on what folks would like to see in the spec.
10:33:10 <dezell> brent: we really didn't intend to go to this level of detail.  I think we've gotten out of this section what we wanted.
10:33:19 <manu> q
10:33:39 <dezell> ... we will submit a PR for what we have, and people can comment on the PR.
10:34:17 <dezell> ... create your own PR to make concrete recommendations for reordering, etc.
10:34:47 <brent> ack drummond
10:35:35 <dezell> drummond: all I want to do is say this session has been productive.  Is it OK with everyone to create a new PR?
10:35:37 <dezell> (nods)
10:35:53 <manu> q-
10:36:18 <dezell> drummond: representation requirements - please think about the representation requirements (slide 178)
10:36:35 <JoeAndrieu> +1 to representation requirements
10:36:40 <dezell> ... I already know that this list isn't complete enough.
10:37:07 <dezell> dan: propose that as a separate PR.
10:37:12 <brent> ack ChristopherA
10:37:12 <Zakim> ChristopherA, you wanted to If the one extensibility data model doesn't allow methods to extend, I like Markus would formally object.
10:37:25 <dezell> ChristonpherA: wanted to support Markus position on extensibility.
10:37:53 <markus_sabadello> q+
10:38:18 <selfissued> q+
10:38:19 <dezell> manu: DB will object if we can't have an open extensibility model.
10:38:28 <brent> ack markus_sabadello
10:38:59 <brent> ack selfissued
10:39:17 <markus_sabadello> From the abstract/charter: "These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, ..."
10:39:31 <manu> s/DB will object if we can't have an open extensibility model./With my Editor's hat off, speaking on behalf of Digital Bazaar, we stand with Danube Tech and will formally object if there is not an appropriate balance wrt. the extensibility model discussed yesterday./
10:39:42 <dezell> mike: all I'm saying is that we agreed on a mechanism.  As long as other mechanisms use that mechanism, we'll be interoperable.
10:39:50 <dezell> Topic: Rubric
10:40:41 <dezell> (Presents Rubric slides)
10:40:45 <Juan_caballero> Juan_caballero has joined #did
10:41:45 <Eugeniu_Rusu_> Eugeniu_Rusu_ has joined #did
10:44:51 <Juancaballero> Juancaballero has joined #did
10:50:37 <SamSmith> q
10:50:43 <SamSmith> q+
10:50:56 <gannan> gannan has joined #did
10:55:37 <ChristopherA> q+
10:55:38 <manu> q+ to note that good documents are timeless, and highlighting DID Methods will make the document look outdated quickly (they're also useful)
10:56:39 <ChristopherA> q+ to Some context, there is no perfect decentralization, all must compromise in some way. The Rubric helps you decide were the acceptable compromises are.
10:56:52 <ivan> -> Current early draft for the rubric document https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit#heading=h.kmwybusdx6vb
10:57:15 <dezell> (presents the draft of the Rubric)
10:57:44 <ChristopherA> q+ to (to YOU, as everyone will choose different compromises)
11:02:49 <brent> q
11:03:26 <Carsten> Carsten has joined #did
11:03:30 <Carsten> q+
11:04:25 <gannan> gannan has joined #did
11:04:33 <dezell> dan: keep in mind that converting to Respec must come before Next PWD.
11:04:50 <dezell> ... so timeframe (July) must consider that.
11:05:08 <brent> ack SamSmith
11:05:29 <dezell> SamSmith: I am surprised I didn't see security model and trust discussed as part of the Rubric
11:05:56 <dezell> Joe: if the issue isn't specifically about decentralization, they might have been missed.
11:05:57 <brent> ack ChristopherA
11:05:57 <Zakim> ChristopherA, you wanted to Some context, there is no perfect decentralization, all must compromise in some way. The Rubric helps you decide were the acceptable compromises are.
11:06:00 <Zakim> ... and to (to YOU, as everyone will choose different compromises)
11:06:14 <brent> q+ to ask about decentralization of how the method may be used
11:06:20 <dezell> ChristopherA: An important discover is that there is no perfect decentralization.
11:06:49 <dezell> ... compromises are going to be required.  Idealism won't work.
11:07:00 <brent> ack manu
11:07:00 <Zakim> manu, you wanted to note that good documents are timeless, and highlighting DID Methods will make the document look outdated quickly (they're also useful)
11:07:28 <dezell> manu: examples are great and terrible at the same time.  My concern is that the examples are going to go stale.
11:07:35 <identitywoman> identitywoman has joined #DID
11:07:42 <identitywoman> q+
11:08:27 <brent> +1 to more categorical examples (striking the actual DID method names)
11:08:34 <dezell> ... there's also an exclusion of the interests of some groups not here.
11:08:45 <dezell> ... we should censure the ledger names in the document itself.
11:09:15 <dezell> ... it might be useful to have a registry where you can have evaluations - self, third-party, community.
11:09:46 <brent> q?
11:10:23 <dezell> JoeAndrieu: I'm against our hosting evaluations.
11:10:33 <dezell> manu: that's OK.
11:10:35 <brent> ack Carsten
11:11:20 <dezell> Carsten: you might get insights on interoperability between did methods.
11:11:41 <brent> ack brent
11:11:41 <Zakim> brent, you wanted to ask about decentralization of how the method may be used
11:11:50 <dezell> Joe: We might have gotten some insights, but I think we should be more intentional about it.
11:12:05 <dezell> brent: is there a Rubric for the decentralization of how the method is used?
11:12:33 <dezell> ... different use cases might have different decentralization.
11:13:01 <brent> ack identitywoman
11:13:09 <dezell> Joe: the method does give some space for that in the answers.
11:13:10 <pam> q+
11:13:55 <ChristopherA> The book is https://mitpress.mit.edu/books/protocol
11:13:59 <dezell> identitywoman: it would be useful to connect decentralization to methods.
11:14:04 <brent> ack pam
11:14:40 <dezell> pam: is there a sense of how many questions people will answer consistently?
11:15:10 <ChristopherA> sample chapter at http://art.yale.edu/file_columns/0000/8696/galloway-ch4.pdf
11:15:23 <dezell> Joe: goal is to produce a 2 page summary, so we id try to make it compact.
11:15:46 <dezell> pam: so how long does it take?
11:16:04 <dezell> Joe: about 1 day.
11:16:27 <gannan> q+
11:16:42 <dezell> drummond:  I think that's about right.
11:16:54 <charles> q+
11:17:04 <dezell> Joe: if you have more people involved in answering it will take longer.  Teams are slower than individuals.
11:17:08 <brent> ack gannan
11:17:21 <drummond> q+
11:17:47 <charles> q-
11:17:55 <dezell> gannan: one day to understand a method in depth, and then have them fill out an evaluation, it's overly ambitious.
11:18:15 <manu> q+ on time and expertise taken to do an evaluation.
11:18:30 <dezell> Joe: If you focus on the parts important to you, you can limit the time.
11:18:57 <dezell> gannan: it's also related to how well the did method is defined.
11:19:04 <dezell> drummond:
11:19:05 <brent> ack drummond
11:19:46 <dezell> drummond: first, how will you get this evaluation done (hire an expert?).
11:20:05 <markus_sabadello> q+
11:20:19 <dezell> ... second, don't just think about individual method authors, think about third-parties.
11:20:43 <brent> q?
11:20:45 <manu> q
11:20:56 <brent> ack manu
11:20:56 <Zakim> manu, you wanted to comment on time and expertise taken to do an evaluation.
11:21:03 <dezell> Joe: running workshops to help educate people is a good idea.
11:21:09 <ivan> present+ yoshiaki
11:21:12 <dezell> manu: I'm worried about the time it takes.
11:21:42 <dezell> ... It takes an enormous amount of time.  Clients want evaluations but don't want to pay for them.
11:21:48 <ivan> zakim, who is here?
11:21:49 <Zakim> Present: burn, ivan, gannan, ewelton, yoshiaki, brent, identitywoman, Joachim, Eugeniu_Rusu, manu, Justin_R, dezell, markus_sabadello, ken, tplooker, charles, selfissued, drummond,
11:21:52 <Zakim> ... nicole, yancy, JoeAndrieu, oliver, Juan_caballero, pamela, ChristopherA
11:21:52 <Zakim> On IRC I see gannan, Carsten, Eugeniu_Rusu_, pam, Justin_R, drummond, ken, tplooker, selfissued, burn, chaals, JoeAndrieu, SamSmith, charles, markus_sabadello, dezell, brent,
11:21:52 <Zakim> ... ewelton, yoshiaki, yofukami, nicole, RRSAgent, Zakim, ivan, presenter, llorllale, SteveTodd, wayne, deiu, rhiaro, ChristopherA, bigbluehat, jfishback, Travis, hadleybeeman,
11:21:53 <Zakim> ... dlehn, manu, dlongley, yancy
11:22:24 <ivan> present+ SamSmith
11:22:32 <dezell> ... there will be "reverse incentives" forcing people to rush through evaluations and give bad data.
11:22:59 <dezell> ... I realize you can select sections, but we might also want to gives some more explicit guideance.
11:23:09 <dezell> s/guideance/guidance/
11:23:15 <ivan> guests+ carsten
11:23:22 <ivan> guests+ ewelton
11:23:52 <brent> ack markus_sabadello
11:23:54 <dezell> joe: there will also be people asking peers "what methods do you use."  There's no explicit evaluation, it's peer recommendation.
11:24:32 <burn> zakim, close the queue
11:24:32 <Zakim> ok, burn, the speaker queue is closed
11:24:42 <dezell> Markus_sabadello: there's no absolute measure in the result of the rubric, but it seems that there should be some "minimum bar".
11:25:14 <selfissued> q+
11:25:24 <dezell> ... maybe establish a registry for did methods.  Do we want a FB method in our registry?
11:26:04 <markus_sabadello> s/FB/Facebook/
11:26:41 <dezell> joe: my wrapup, want to turn this over to the chairs and get consensus on an FPWD.
11:26:55 <dezell> brent: we will select editors, etc. as part of that process.
11:27:12 <dezell> joe: this has been an amazing exercise.
11:27:18 <gannan> Can we add the rubric google doc directly into the minutes JoeAndrieu?
11:27:24 <brent> q?
11:27:34 <burn> zakim, open the queue
11:27:34 <Zakim> ok, burn, the speaker queue is open
11:28:21 <dezell> mike: my experience as an expert for registries, make sure that requested entries are understandable and actionable, but avoid saying "your submission is not good enough."
11:28:55 <dezell> ... we should welcome all comers as long as their submission is clear and actionable.
11:29:10 <dezell> joe: I agree with that.
11:29:25 <ivan> rrsagent, draft minutes
11:29:25 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html ivan
11:37:31 <gannan_> gannan_ has joined #did
12:03:14 <charles> charles has joined #did
12:10:48 <dezell> dezell has joined #did
12:14:31 <gannan> gannan has joined #did
12:22:59 <ken> ken has joined #did
12:23:16 <ivan> Topic: Use cases
12:23:35 <ivan> Slides starting at https://docs.google.com/presentation/d/1XI5rrEdBUSYd2tW07GfzOjBkvgKmfeKQyh95Ekl-u8o/edit#slide=id.g76bd51c181_18_255
12:30:16 <Justin_R> Justin_R has joined #did
12:30:19 <tplooekr> tplooekr has joined #did
12:30:28 <tplooker> tplooker has joined #did
12:30:29 <gannan> gannan has joined #did
12:30:30 <tplooker> present+
12:30:36 <drummond> drummond has joined #did
12:30:38 <drummond> present+
12:30:49 <ivan> scribe+ drummond
12:31:42 <tplooker> q?
12:31:52 <drummond> topic: Use Cases & Requirements
12:32:02 <selfissued> selfissued has joined #did
12:32:07 <drummond> Joe explained that Phil Archer could not be here today.
12:32:36 <drummond> This starts at what is currently slide 194 in the F2F slide deck
12:33:10 <drummond> The main reason for use cases & requirements is to focus our work and make sure it addresses the actual needs
12:33:29 <drummond> It is also to communicate to others the value of our work
12:33:36 <Carsten> Carsten has joined #did
12:34:30 <drummond> It is also to capture the consensus of the WG
12:34:37 <drummond> And to capture requirements
12:34:49 <ivan> q+ to emphasize other reason for having this document
12:34:50 <drummond> The current draft was started in the Credentials Community Group
12:35:23 <drummond> Joe emphasized that the use cases document should not talk about specific technology or solutions.
12:35:38 <drummond> Currently the doc has 5 focal use cases.
12:36:51 <drummond> 1) Corporate Identifiers, 2) Life-long Recipient-Managed Credentials, 3) Prescriptions, 4) Digital Executor, 5) Single-Sign On
12:38:03 <drummond> Joe explained the Digital Executor use case involves long-lived delegations to a trusted party like an executor
12:39:21 <drummond> The previous use cases are FOCAL, so each is explained in depth. There are currently five more brief use cases.
12:40:02 <drummond> 1) Online Shopper, 2) Vehicle Assemblies, 3) Encrypted Data Vault, 4) Accessing service endpoints, 5) Verifiable Credentials
12:40:19 <drummond> The brief use cases are each just one paragraph.
12:40:42 <drummond> There are still issues around terminology. The document does share one terminology section.
12:41:53 <drummond> There is one outstanding set of issues around roles. The open question is around the role for someone who is using a DID but is neither the DID Controller or the DID Subject.
12:42:07 <markus_sabadello> markus_sabadello has joined #did
12:42:15 <drummond> The main current task is for contributors to write up use cases.
12:42:53 <ken> q+
12:43:16 <drummond> Slide 203 has instructions on "How to Help: Brief Uses Cases"
12:43:52 <drummond> Write up one specific value-creating interaction. It is not a category, not a list.
12:44:25 <drummond> Be specific: make it about a real person with a clear, motivation.
12:45:03 <drummond> Describe what they do, doing a real task. Not why. Not how. "Just the facts, ma'am."
12:45:03 <ewelton> q+ to ask if the only possible subject of a did is a person "I want a real person, talk about Sally" - at 13:44....... 100% of the explanation is about people, not things
12:45:25 <drummond> Be distinct: cover a feature not already covered.
12:46:43 <brent> q?
12:47:01 <ChristopherA> q+ to ask "How do we get at least one FOCAL use case for trustless SSI as opposed to Legally Enabled SSI."
12:47:02 <drummond> Slide 204: Joe talked about different possible domains and use cases. Examples: IoT. Crypto. Authorization. Extensibility.
12:53:50 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
12:56:04 <JoeAndrieu> JoeAndrieu has joined #did
12:56:09 <ivan> ivan has joined #did
12:56:30 <gannan> gannan has joined #did
12:57:19 <brent> brent has joined #did
12:57:20 <markus_sabadello> markus_sabadello has joined #did
12:57:26 <dezell> dezell has joined #did
12:57:31 <Joachim> Joachim has joined #did
12:57:34 <drummond> drummond has joined #did
12:57:37 <drummond> present+
12:57:38 <tplooker> tplooker has joined #did
12:57:40 <tplooker> present+
12:57:43 <drummond> scribe+
12:57:48 <selfissued> selfissued has joined #did
12:57:50 <SamSmith> SamSmith has joined #did
12:57:50 <selfissued> present+
12:57:51 <markus_sabadello> stillpresent+
12:57:55 <ivan> rrsagent, draft minutes
12:57:55 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html ivan
12:57:59 <brent> q?
12:58:37 <drummond> Joe Andrieu continues (after a wifi network outage)
12:59:10 <brent> q+ to ask about DID Comms
12:59:10 <drummond> ...Possible Domains and Use Cases (slide 204 in the current slide deck)
12:59:16 <charles> charles has joined #did
12:59:45 <drummond> ...Joe provided several examples of these brief use cases in order to spur others to submit new ones
13:00:24 <drummond> ...he used the example of a bank who wants to delegate a specific capability to Joe, who can then redelegate to others.
13:01:03 <drummond> ...Joe wants his assistant, controller, and CPA, and he wants all of them to have different permissions
13:01:43 <drummond> ...DIDs can enable all of the parties to a delegation chain to rotate their keys, when combined with other delegation mechanisms
13:02:39 <drummond> ...Joe's reaction to Brent's suggestion: "It would almost be as great as keeping the Chair on the queue" <wild laughter>
13:03:10 <brent> q
13:03:33 <markus_sabadello> q+
13:03:41 <drummond> ...Another example is chain of authority, i.e., having clear delegation chains via DIDs and verifiable credentials.
13:03:43 <brent> q+ to say many of the use cases feel like they are petter served by VCs and DIDs are ancillary
13:03:56 <drummond> ...Currently, we have nothing about extensibility
13:04:27 <drummond> ...currently we don't have any innovative examples of extensibility. Joe invites a use case about it.
13:04:57 <drummond> drummond: Sign me up for one use case about service endpoints.
13:05:17 <juan_caballero> juan_caballero has joined #did
13:05:20 <drummond> Joe Andrieu: Asks for other use cases on service endpoints.
13:05:48 <drummond> markus_sabadello: will add a use case about proxy resolution.
13:06:11 <drummond> ChristopherA: Was wondering about use cases for BTCR
13:06:12 <ChristopherA> q
13:06:27 <Carsten> Carsten has joined #did
13:06:33 <brent> q?
13:06:36 <drummond> Joe Andrieu: Asks for everyone's input about additional use cases.
13:06:39 <brent> ack ivan
13:06:39 <Zakim> ivan, you wanted to emphasize other reason for having this document
13:06:42 <Carsten> q+
13:06:43 <drummond> Going to queue now
13:06:46 <ewelton> ewelton has joined #did
13:06:47 <ewelton> present+
13:07:20 <ChristopherA> q+ to ask "Are there any non-people DID keys where the "thing" has keys, and those were the "thing" is delegated keys?"
13:07:24 <drummond> ivan: One more very important point to keep in mind: some of us will be involved in presenting DID tech to outsiders. Use cases help very much for this.
13:07:36 <drummond> ...short but clear use cases is really very important for this.
13:07:44 <juan_caballero> +1
13:07:56 <drummond> JoeAndrieu: Strongly agrees.
13:08:12 <brent> q?
13:08:44 <drummond> ...Joe is looking for the 1-minute video of a use case that's very clear for DIDs
13:09:07 <drummond> ivan: What is missing also is "How do I use the spec to solve these things".
13:09:23 <brent> q+ to say what ivan suggested sounds like implementation guidance
13:09:37 <drummond> ...doing that for all use cases in the doc would be very hard, but picking a few and doing that for those would be very helpful.
13:09:42 <brent> ack ken
13:10:37 <drummond> Ken Ebert: had several examples that he thinks he can contribute. One of them was verifiable credentials, but of specific types.
13:10:45 <yoshiaki> yoshiaki has joined #did
13:11:00 <drummond> ...he will sign up to look at those for healthcare.
13:11:01 <brent> ack ewelton
13:11:01 <Zakim> ewelton, you wanted to ask if the only possible subject of a did is a person "I want a real person, talk about Sally" - at 13:44....... 100% of the explanation is about people, not
13:11:04 <Zakim> ... things
13:11:40 <drummond> ewelton: Every use case for naming "things" could be submitted.
13:11:40 <yofukami> yofukami has joined #did
13:12:01 <Chunming> Chunming has joined #did
13:12:13 <drummond> JoeAndrieu: Use cases should stress people. Examples of using them for cats is weaker.
13:12:18 <brent> ack ChristopherA
13:12:18 <Zakim> ChristopherA, you wanted to ask "How do we get at least one FOCAL use case for trustless SSI as opposed to Legally Enabled SSI." and to ask "Are there any non-people DID keys where
13:12:21 <Zakim> ... the "thing" has keys, and those were the "thing" is delegated keys?"
13:12:29 <ken> ken has joined #did
13:12:30 <drummond> ewelton: Signed up for a use case about naming cats.
13:13:28 <drummond> ChristopherA: Some people have "abandoned" DIDs because they all use cases are around "legally-enabled SSI" (LESS).
13:13:35 <pam> pam has joined #did
13:13:47 <pam> q+ (on behalf of Kaliya)
13:13:56 <pam> q+
13:14:10 <drummond> ...but they are much more interested in true "self-sovereign identity" or "trustless" identity, and so we need them to be "focal" use cases.
13:14:37 <drummond> ...in particular ONE of the five use cases that's not about legally-enabled digital identity
13:15:07 <drummond> ...also wants to see an example of a use case that's about enabling something to exist because it's been given keys.
13:15:35 <ewelton> q+ to capturing the "range of agency" somewhere in the Focal
13:15:36 <brent> ack brent
13:15:37 <Zakim> brent, you wanted to ask about DID Comms and to say many of the use cases feel like they are petter served by VCs and DIDs are ancillary and to say what ivan suggested sounds like
13:15:37 <Zakim> ... implementation guidance
13:15:41 <drummond> JoeAndrieu: Does not want to have more than 5 focal use cases.
13:15:44 <drummond> q+
13:16:15 <drummond> brent: Some of the use cases are not about DIDs so much as about verifiable credentials.
13:16:33 <drummond> ...What Ivan mentioned is more of an "application guide".
13:16:33 <Justin_R> Justin_R has joined #did
13:16:36 <brent> ack markus_sabadello
13:16:36 <drummond> q?
13:17:04 <drummond> markus_sabadello: Liked what Christopher Allen said about the "trustless" use cases, but there were some limits on it in the charter.
13:17:22 <drummond> ...such as "I want to avoid paying taxes". Is that out of scope?
13:17:40 <drummond> JoeAndrieu: The place to draw that line is "extra-legal", not "illegal".
13:17:52 <drummond> ...legality can be tied to a specific sovereign state.
13:18:03 <drummond> ...and no one is advocating anything like that.
13:18:04 <juan_caballero> another terminological tweak: non-state, not anti-state
13:18:15 <juan_caballero> #commentingForAFriend
13:18:29 <brent> ack Carsten
13:18:34 <drummond> ...the Red Cross is a great example. In Joe's own case, his apartment burned down and the Red Cross showed up to help and did not ask for ID.
13:18:36 <manu> q+ to note that we have a WG now, we are publishing a note, we can put in a "I want to create a new digital nation." use case.
13:19:16 <drummond> Carsten: We might want to structure use cases by entity type. People, orgs, IoT objects, physical objects.
13:19:38 <drummond> ...example is giving DIDs to cars. Various autonomic things.
13:19:54 <drummond> ...would like to volunteer to do those.
13:19:55 <brent> ack pam
13:20:02 <drummond> JoeAndrieu: Yes, those would be great.
13:20:50 <drummond> Kaliya: Speaking for Wireline, they are looking for highly decentralization applications, and she will provide some use cases for those scenarios.
13:21:03 <drummond> ...sometimes those are called DWeb or Web 3.0.
13:21:10 <brent> ack ewelton
13:21:10 <Zakim> ewelton, you wanted to capturing the "range of agency" somewhere in the Focal
13:21:26 <drummond> ...they are not necessarily engaging, and we are potentially going to miss them if we don't speak up.
13:21:38 <juan_caballero> Editorial suggestion: maybe better to have a list of identity types (natural person, legal person, machine, software/AI, product (abstract), product (specific)) as a matrix-- list for each use case home many are involved, so that people can search/filter by all use-cases involving in in any way
13:22:01 <drummond> ewelton: There should be IoT use cases that do not involve any "agency" of some other authority.
13:22:19 <brent> ack drummond
13:22:21 <juan_caballero> +1 to Kaliya's point about alternative networks and their different environmental, networking, and liability  assumptions
13:22:27 <drummond> ...so there needs to be an ability to "point at things" and "name things' without using a centralized authority.
13:22:29 <brent> scribe+
13:22:50 <brent> drummond: It occurs to me that a compelling use case is something you can only do with DIDs
13:23:19 <brent> ... Forming a connection between two human beings that can last for all time with no central intermediary
13:23:45 <brent> ... it was something that has never been possible before
13:23:49 <brent> q?
13:23:58 <brent> ack manu
13:23:58 <Zakim> manu, you wanted to note that we have a WG now, we are publishing a note, we can put in a "I want to create a new digital nation." use case.
13:24:02 <drummond> scribe+
13:24:29 <markus_sabadello> q+
13:24:30 <drummond> manu: I've heard a few people say there's constraints on what we can and can't do in the use cases.
13:24:41 <drummond> ...for example, creating a new Digital Nation is a real use case.
13:25:00 <drummond> ...and one of the best ways to reach out to those parties is to write up those use cases.
13:25:08 <drummond> ...they should be invited in.
13:25:09 <pam> q+
13:25:26 <drummond> ...and Manu would like to see us write up those use cases.
13:25:26 <juan_caballero> +1, lots of non-state people are very active on github, if you leave the issue open they will find it :D
13:26:06 <gannan> gannan has joined #did
13:26:15 <juan_caballero> particularly since this happened: https://www.theverge.com/2019/4/22/18511088/microsoft-github-tech-censorship-996-repository-china
13:26:20 <brent> ack markus_sabadello
13:26:27 <drummond> JoeAndrieu: Wanted to clarify that use cases are not constrained to "what exists today", but can talk about future situations.
13:26:56 <brent> ack pam
13:26:59 <drummond> markus_sabadello: Wanted to endorse the inclusion of VRM (Vendor Relationship Management) use cases.
13:27:19 <drummond> Kaliya: Ambassadorship (for the DID WG) is very important.
13:27:49 <drummond> ...there was an example at a recent conference where a member of our community "overevangelized".
13:28:08 <brent> zakim, close the queue
13:28:08 <Zakim> ok, brent, the speaker queue is closed
13:28:11 <drummond> ...we need to be sensitive about others concerns about control and decentralization.
13:28:47 <drummond> JoeAndrieu: He has not heard anything about vulnerable populations using DIDs.
13:29:00 <drummond> SamSmith: Volunteered a use case in that area.
13:29:14 <drummond> ewelton: Also volunteered a use case in that area.
13:29:30 <drummond> JoeAndrieu: Was very pleased with the number of new ideas.
13:29:38 <juan_caballero> I would be glad to refine previously-submitted case about anonymous sources and journalist safety
13:29:40 <drummond> Also excited about the non-VC examples that were raised.
13:29:44 <brent> zakim, open the queue
13:29:44 <Zakim> ok, brent, the speaker queue is open
13:32:14 <ken> ken has joined #did
13:35:56 <presenter> presenter has joined #did
13:37:26 <burn> burn has joined #did
13:49:33 <juan_caballero> scribe+
13:49:51 <ivan> Topic: Metadata
13:50:00 <ken> ken has joined #did
13:50:29 <ivan> -> slides https://docs.google.com/presentation/d/1XI5rrEdBUSYd2tW07GfzOjBkvgKmfeKQyh95Ekl-u8o/edit#slide=id.g477278097e_1_114
13:50:38 <juan_caballero> thank you ivan
13:51:10 <JoeAndrieu> q+
13:51:23 <juan_caballero> burn: explanation of metadata concretization exercise
13:51:41 <gannan> gannan has joined #did
13:51:45 <gannan> q+
13:52:09 <juan_caballero> ... I want everyone to give concrete examples of properties (in a DIDDOC), and what their implementation does/will use it for; optionally, also how they get it and where it goes
13:52:10 <Justin_R> q+ to give a property
13:52:40 <drummond> q+
13:52:54 <juan_caballero> ... [correction: not just properties in a DIDDoc, but also pieces of metadata and debatable things that might be metadata for some but not others]
13:53:07 <Justin_R> ack JoeAndrieu
13:53:07 <brent> ack JoeAndrieu
13:53:14 <manu> q+ to speak for @context, id, publicKeys
13:53:32 <juan_caballero> joe: what you said and the slide don't line up well?
13:53:38 <juan_caballero> burn: yup, i'll edit the slide
13:53:54 <juan_caballero> burn: by "come from", I meant, pre-existing, spit out by resolution process, etc
13:53:56 <markus_sabadello> q+
13:54:10 <manu> q+ to speak for authentication, service.
13:54:23 <juan_caballero> ack drummond
13:55:09 <juan_caballero> drummond: these things we're brainstorming are all things that end up where? in spec?
13:55:16 <manu> q+ to note capabilityDelegation and capabilityInvocation.
13:55:26 <juan_caballero> burn: it's things the speaker needs spec'd somewhere, but they might end up in diff places
13:55:32 <juan_caballero> ... or not spec'd at all
13:55:46 <juan_caballero> drummond: how's it go?
13:55:52 <brent> ack markus_sabadello
13:55:59 <juan_caballero> burn: one per slide, edit or add, discussed separately
13:56:17 <juan_caballero> markus_sabadello:
13:56:27 <juan_caballero> manu: we're not debating what's already in the spec, are we?
13:56:49 <juan_caballero> burn: nope, we're trying to get clarity on did doc versus metadata versus resolution header question
13:57:04 <ChristopherA> q+ to Ask "Where can we have progressively disclosed information rather than disclosing it? For instance, no public key -> public key hash -> public key. The error code should not be a hard FAIL, but soft UNRESOLVED, and not VALID."
13:57:06 <juan_caballero> manu: does that cover data inside keys (owner, type)? i have a list of 35 in my head already!
13:57:44 <tzviya> tzviya has joined #did
13:58:45 <juan_caballero> burn: i'm trying to avoid submerged mines and unrecognized disagreements, partic about properties being metadata/diddoc/resolution
13:59:34 <juan_caballero> ack drummond
13:59:44 <juan_caballero> drummond: we might have 100 here pretty quickly?
13:59:46 <ChristopherA> q+ to Ask "BTCR has anti-sybil signals, how much funds are locked up, funds expended" that apps care about, but it isn't clear if a resolver should add them to the DID document, but it is really signed by the chain, not the user."
13:59:48 <ChristopherA> q
13:59:59 <juan_caballero> burn: of course! i just want to identify disagreements
14:00:11 <juan_caballero> gannan, i feel you
14:00:37 <JoeAndrieu> q+ for authoredTime
14:00:49 <juan_caballero> tobias: start with the controversial ones?
14:00:49 <ken> q+
14:00:56 <juan_caballero> manu: +1
14:01:04 <juan_caballero> ack burn
14:01:50 <juan_caballero> burn: no more process questions?
14:02:08 <juan_caballero> drummond: slide scribe? who's updating the deck?
14:02:39 <brent> ack gannan
14:02:51 <juan_caballero> ganesh: i dont have a name, exactly
14:03:00 <juan_caballero> ... but I want a timestamp of did RESOLUTION
14:03:08 <juan_caballero> ... ("when it was resolved")
14:03:24 <juan_caballero> ... 2.) I want a self-attested timestamp about did creation from its controller
14:03:39 <markus_sabadello> q+
14:03:48 <juan_caballero> burn: process, let's build list first and come back to why and how
14:04:11 <juan_caballero> ganesh: for cache invalidation
14:04:27 <chaals> chaals has joined #did
14:04:40 <juan_caballero> ... (that's what i want #1 for)
14:05:36 <juan_caballero> burn: #1 where it comes from? how's it generated?
14:05:46 <juan_caballero> ganesh: the process ? the resolver?
14:06:00 <juan_caballero> justin: that's who asked, not who answered
14:06:06 <juan_caballero> ganesh: then leave it as "the process" for now?
14:06:20 <juan_caballero> ganesh: #2 is for metadata ing things
14:06:25 <juan_caballero> burn: no
14:06:35 <juan_caballero> burn: if it's proprietary, you can say that, but that's not much less circular
14:06:40 <oliver> oliver has joined #did
14:06:41 <oliver> present+ oliver
14:07:21 <juan_caballero> burn: let's add a C subheading for name of proposer to check back after discussion/iteration
14:07:41 <juan_caballero> burn: so where's the timestamp #1 come from, tho?
14:08:01 <juan_caballero> burn: where's #2 come from, exactly?
14:08:09 <juan_caballero> ganesh: DID controller is who i mean by "self-attested"
14:08:10 <brent> ack Justin_R
14:08:10 <Zakim> Justin_R, you wanted to give a property
14:08:32 <juan_caballero> Justin_R: mime/type
14:09:01 <juan_caballero> ... "document serialization format", more generally; there are alternatives to MIME
14:09:17 <juan_caballero> ... and I don't want to assume that's the best way to know how to deserialize a bunch of 1s and 0s
14:09:24 <juan_caballero> ... i care about this as code dispatch
14:09:30 <juan_caballero> ... it comes from output of resolution
14:09:40 <juan_caballero> ... (not dereferencing)
14:09:49 <juan_caballero> burn: next
14:09:58 <juan_caballero> ...slide
14:10:02 <brent> ack manu
14:10:02 <Zakim> manu, you wanted to speak for @context, id, publicKeys and to speak for authentication, service. and to note capabilityDelegation and capabilityInvocation.
14:10:11 <ChristopherA> q
14:10:21 <juan_caballero> manu: can i put a prop on there that I want RIPPED OUT of the spec
14:10:23 <oliver> q+
14:10:31 <juan_caballero> ...or at least, ripped out of the did doc
14:10:45 <juan_caballero> ... (i'll come back to it)
14:11:01 <juan_caballero> ... i want a property that capability can be invoked or delegated
14:11:13 <oliver> q+
14:11:22 <juan_caballero> ... #1 capability invocation and #2 capability delegation
14:11:38 <juan_caballero> JoeAndreiu: I don't speak OCap, please clarify for those of us in the back?
14:11:55 <juan_caballero> Manu: key material used to invoke an OCap
14:12:20 <juan_caballero> Manu: DID controller provides both keys
14:12:24 <juan_caballero> ...directly
14:13:19 <juan_caballero> ...burn: is it a private key?
14:13:51 <oliver_> oliver_ has joined #did
14:13:52 <SamSmith> q
14:13:57 <oliver_> present+ oliver_terbu
14:14:01 <oliver_> q+
14:14:04 <juan_caballero> manu: no, it's the public key assoc with a private key
14:14:05 <SamSmith> q+ to
14:14:27 <juan_caballero> ... it's not a valet key, it's the action of being given the valet key
14:14:44 <juan_caballero> tobias: it's like a fingerprint reader ON the valet key
14:14:47 <SamSmith> q+ to proof of current control authority over DID
14:15:03 <juan_caballero> tplooker, not tobias
14:15:25 <juan_caballero> burn: i'm trying to avoid everyone thinking of DID Controller as an entity
14:15:45 <juan_caballero> joeAndreiu: I think you're worried about a conflation between human user and software agent?
14:15:49 <juan_caballero> burn: I want to be extra clear here
14:16:05 <juan_caballero> JoeAndreiu: can we tease it out [ChristopherA: later?]
14:16:18 <juan_caballero> Drummond: ... (clarifying)
14:16:24 <juan_caballero> Manu: let's table this for now!
14:16:42 <juan_caballero> burn: but this clarification is useful to others adding to the list!
14:17:35 <brent> q?
14:17:38 <juan_caballero> manu: #2- also can come from any entity
14:17:45 <tplooker> q+
14:18:00 <juan_caballero> ganesh: #2 i meant software agent by DID controller
14:18:03 <juan_caballero> burn: aha!
14:18:14 <brent> ack ChristopherA
14:18:14 <Zakim> ChristopherA, you wanted to Ask "Where can we have progressively disclosed information rather than disclosing it? For instance, no public key -> public key hash -> public key. The
14:18:15 <juan_caballero> burn: this is why I wanted to tease out these differences of assumption!
14:18:17 <Zakim> ... error code should not be a hard FAIL, but soft UNRESOLVED, and not VALID." and to Ask "BTCR has anti-sybil signals, how much funds are locked up, funds expended" that apps care
14:18:17 <Zakim> ... about, but it isn't clear if a resolver should add them to the DID document, but it is really signed by the chain, not the user."
14:18:34 <Joachim> Joachim has joined #did
14:19:02 <juan_caballero> ChristopherA: I want a "versioning" assertation by the creator of a DID as to that particular version of the DID
14:19:13 <juan_caballero> ... not its underlying blockchain anchoring, key rotation mechanics, etc
14:20:14 <juan_caballero> ... I am calling it a "Controller Version" , it is from the DID Controller ("a person"), and it's for the relying party to know what happened if an underlying blockchain changed but without the controller knowing about it or caring
14:20:17 <juan_caballero> ... it's a trust thing
14:20:38 <juan_caballero> JoeAndreiu: This sounds like a surprising thing for the human to know or understand?
14:21:00 <juan_caballero> ChristopherA: OK, maybe it's usually the agent, but it's the agent acting on behalf of the person, as opposed to the blockchain
14:21:14 <juan_caballero> ChristopherA: #2: I'm calling this one "Controller Redacted"
14:21:27 <juan_caballero> ... you don't need the public key
14:21:47 <manu> q+ for Verification Method
14:21:49 <juan_caballero> ... I'm imagining an indirection/minimal disclosure situation
14:22:22 <juan_caballero> ... so that a public key is granted by a DID Doc only after a legit business reason has been proven
14:23:01 <juan_caballero> ... For: Controller to redact/minimally disclose information (i.e. a public key)
14:23:32 <juan_caballero> Drummond: It's still not very clear to me, can we rename it or reword it
14:23:51 <juan_caballero> JoeAndreiu: Controller: [REDACTED]
14:24:21 <juan_caballero> ChristopherA: #3: AntiSybil and/or reputation info
14:25:11 <juan_caballero> ...: for: allows the verifier to evaluate trust based on skin in the game, age of DID, etc
14:25:31 <juan_caballero> ...: from: network (i.e., blockchain), not controller.  FOR NOW resolver has to give/find this info on its own
14:25:45 <juan_caballero> ...: but the user of a DID is who needs it, it needs to come from somewhere\
14:25:47 <brent> q?
14:25:49 <juan_caballero> Drummond: new slide
14:26:02 <brent> ack JoeAndrieu
14:26:02 <Zakim> JoeAndrieu, you wanted to discuss authoredTime
14:26:17 <juan_caballero> joeAndreiu: I wanna add to Ganesh's, possibly
14:26:43 <juan_caballero> ...: ganesh's #2 (self-attest timestamp at creation): for: validation of temporal flow
14:26:54 <juan_caballero> ganesh: yes i agree, go ahead and reword it
14:27:06 <juan_caballero> burn: add joe to the C.) for future discussion
14:27:34 <ken> q-
14:27:38 <juan_caballero> joeAndreiu: this self-attestation, if it doesn't line up with timeline of other relevant facts, would be helpful to raise red flags
14:27:50 <juan_caballero> joeAndreiu: I want to add a new prop: "Retired Keys"
14:28:46 <brent> q?
14:28:50 <brent> ack markus_sabadello
14:28:55 <juan_caballero> ... for: key validation of keys that haven't been revoked but have been rotated and are not the current key
14:29:05 <juan_caballero> ... from: DID Controller (software)
14:29:11 <juan_caballero> Markus_sabadello:
14:29:45 <juan_caballero> 1 DID Created, 2 DID Updated, 3 DID Deactivated
14:30:08 <juan_caballero> markus_sabadello: 1 DID Created, 2 DID Updated, 3 DID Deactivated
14:30:19 <manu> q manu
14:30:30 <manu> s/q manu//
14:30:32 <manu> q
14:30:45 <juan_caballero> ... 1 for: checking if a DID was available before a certain date , from: Verifiable Data registry
14:31:34 <juan_caballero> ... 2 for: cacheing and invalidation, from: VDReg
14:32:07 <manu> q+ to suggest "controller" - the entity that has control authority over the DID (might duplicate Sam's request)
14:32:18 <manu> q- oliver_
14:32:19 <manu> q- to
14:32:21 <juan_caballero> ... 3 for: checking date up until which a DID existed
14:32:33 <juan_caballero> ... from: same VDReg
14:32:44 <SamSmith> q
14:33:06 <juan_caballero> ...4 DIDDoc Version number: Similar to ChristopherA's DID Versioning, but not from DID controller
14:33:22 <juan_caballero> ... from: VDReg
14:34:25 <juan_caballero> ...5 DIDDoc CachedFlag: Whether fresh resolution or cached doc, for: trust judgments, from: Resolver
14:34:29 <brent> q?
14:35:32 <juan_caballero> JoeAndreiu: Clarification question: Are these timestamps by def? Can we clarify which of these are/should be timestamps?
14:35:40 <juan_caballero> Markus_sabadello: sure, but not #5
14:35:55 <juan_caballero> ... also, #4 should be version identifier, not necessarily number or string
14:36:00 <brent> ack oliver
14:36:15 <juan_caballero> christopherA: yes mine as well should not be limited/assumed to be a number
14:36:25 <gannan> gannan has joined #did
14:36:33 <gannan> q+
14:37:49 <juan_caballero> Oliver_terbu: #1 resolver version
14:38:01 <juan_caballero> drummond: what about driver version? etc?
14:38:17 <juan_caballero> Oliver_terbu: #1 for security from resolver
14:38:31 <juan_caballero> ... #1 rename resolver SPEC version
14:38:52 <juan_caballero> ... #2 resolver METHOD CODE version from resolver for security
14:39:28 <juan_caballero> ... #3 Resolver Engine Code Version for security from resolver
14:39:31 <ChristopherA> q+ to ask "A BTCR resolver can know that the DID is on a test network (it has an x in it) but should it be explicitly in the DID Doc"
14:40:19 <brent> ack SamSmith
14:40:19 <Zakim> SamSmith, you wanted to proof of current control authority over DID
14:40:29 <juan_caballero> Pam: if there's a breach, this would be very useful for forensic analysis of whom to warn, who authenticated in a given period, etc
14:40:37 <juan_caballero> ...: so i support this
14:40:47 <juan_caballero> SamSmith: Verifiable Proof of Control Authority
14:41:44 <juan_caballero> ... (to Manu's clarification): I mean the root control of the DID, i.e. root control of a DID's key
14:42:07 <juan_caballero> tplooker: DID doc verification methods?
14:42:25 <juan_caballero> SamSmith: no, this is control of the DID, verification is a subset of that
14:42:41 <juan_caballero> ...: this is ROOT LEVEL control, other subsets of controls
14:43:19 <juan_caballero> ...: we can bikeshed the exact meaning of root control, but i'd leave it at that for now
14:43:28 <pam> scribe+
14:43:29 <brent> scribe+ pam
14:43:54 <pam> SamSmith: because it is verifiable, in aggregate it can be variable
14:44:27 <pam> SamSmith: this must be a cryptographic proof
14:45:01 <pam> ...: two formats:  either the full proof or a hash and a reference to find the proof
14:45:03 <markus_sabadello> q+
14:45:40 <pam> ... (to clarify regarding what kinds of proofs) - could be any kind of proof
14:46:00 <brent> q?
14:46:39 <brent> ack tplooker
14:46:49 <pam> tplooker:  clarification to Justin's property
14:47:24 <pam> ...: a party that wants to resolve a did  (did client) should be able to express a did resolver option requesting a mime-type they prefer
14:48:32 <pam> ...: (justin_r says content-type, but tplooker's property is requested content type)
14:49:05 <pam> ... possible organization is "resolver options"
14:49:53 <pam> Samsmith: usually in a verifiable proof (eg rotation keys) also gives any keys that have been retired
14:50:39 <pam> brent: should we switch to did resolution relationship?
14:52:14 <pam> tplooker:  extension to delegation property - both properties are assertions by did controller about which verification methods are authorized to invoke or delegate on behalf of the did subject
14:53:33 <pam> ... new property:  assertion - for a did controller to express verification methods authorized to assert things on behalf of the did subject
14:54:59 <pam> ... example: which keys in the DID doc are authorized to issue VCs?
14:55:31 <pam> ... (various concerns about wording)
14:55:57 <brent> q?
14:56:08 <pam> ... noted:  nobody is happy with the name "Assertion", needs to be solved for future
14:56:15 <manu> q+ to note keyAgreement
14:56:21 <juan_caballero> ^ (some people like assertion, some assertionProof, some issuance, some issuanceAuthority ...*
14:56:22 <juan_caballero> )
14:56:26 <brent> ack manu
14:56:26 <Zakim> manu, you wanted to discuss Verification Method and to suggest "controller" - the entity that has control authority over the DID (might duplicate Sam's request) and to note
14:56:30 <Zakim> ... keyAgreement
14:56:33 <oliver> oliver has joined #did
14:56:34 <oliver> q+
14:56:43 <pam> manu: 100% agreement with Sam re: controller but then...
14:56:49 <Justin_R> Justin_R has joined #did
14:57:21 <pam> ... new item proposed: controller - typically the entity for expressing the entity that is in control of the identifiers associated
14:58:01 <pam> ... not the same as SamSmith's proof (control authority), Sam's property is keys
14:58:16 <pam> ... manu's point is an indirection that can lead to keys rather than being the keys
14:58:39 <pam> manu:  what is at the end of the rainbow for SamSmith:  answer is keys
14:59:04 <brent> q?
14:59:29 <pam> ... what is at the end of manu's rainbow:  dids
14:59:52 <pam> ...  manu believes concepts are compatible
15:00:15 <pam> manu:  asking ganesh about encrypted data vaults - were there keys pulled from did doc?
15:00:27 <juan_caballero> (discussion to tease out compatibility-- manu calls it an indirection to another DID [controller], Sam calls it an indirection to the proof of ultimate key control)
15:00:51 <pam> ... new property:  key agreement key -- for establishing encrypted comms
15:01:09 <ChristopherA> q
15:01:13 <pam> ganesh:  read a definition he will annotate
15:01:21 <gannan> The key agreement key is used to derive a secret that is then used to
15:01:21 <gannan> generate a key encryption key for the receiver.
15:01:53 <pam> burn:  noting all of these properties are from the did controller
15:01:56 <ChristopherA> q+ 2 - flag could be a non-accountable multisig
15:02:04 <ChristopherA> q+ to 2 - flag could be a non-accountable multisig
15:02:07 <ChristopherA> q
15:02:08 <brent> q?
15:02:15 <brent> ack gannan
15:02:25 <pam> gannan: update to Markus' did_created, updated etc
15:02:41 <pam> ... the timestamp at which the verifiable data registry finished the CRUD operation
15:03:04 <pam> ... drummond asks gannon to add those definitions to slides 213/214
15:03:06 <SamSmith> q+
15:03:22 <pam> ... when the did can be resolved after the changes are made
15:03:28 <markus_sabadello> i agree with gannan 's changes
15:04:07 <pam> christophera: concerned that in BTCR there is a flag hidden in the value that lets the resolver know that the did is a testnet DID
15:04:28 <pam> ... today that value is just 2 networks, should we have a field in the DID itself that says that the identifier is a test?
15:04:44 <pam> ... also should the resolver also say that it has recognized a test?
15:04:48 <brent> ack ChristopherA
15:04:48 <Zakim> ChristopherA, you wanted to ask "A BTCR resolver can know that the DID is on a test network (it has an x in it) but should it be explicitly in the DID Doc" and to 2 - flag could be
15:04:51 <Zakim> ... a non-accountable multisig
15:05:05 <pam> ... what if you could fool a client that isn't fully resolving the work itself?
15:05:44 <pam> joe: suggests target network and actual network as terminology
15:06:28 <pam> christophera:  there is a user intent that right now isn't representative
15:06:39 <pam> gannan:  is this for a specific network identifier?
15:07:05 <pam> christophera:  somebody should be able to have a sovereign plane but the client might not know that a testnet did is part of that plane
15:08:03 <pam> brent: it sounds like the target verifiable data registry identifier is part of the did not the did doc?   (ChristopherA agrees)
15:08:41 <pam> brent:  if you ignore where it comes from, a did document that came from a testnet network looks the same, is not identifiable
15:09:14 <pam> oliver:  there is a column after the did in the did document where this could be notated
15:09:44 <pam> JoeAndrieu: if you think you're getting back a real document from mainnet but the creator thought it was a test, that would be good to know
15:10:12 <pam> ... 3 different areas to coordinate - in the identifier, in the did doc, and ?
15:10:20 <SamSmith> q
15:10:36 <pam> burn:  do we need all three separate pieces of information or is it the same piece of data in 3 places?
15:10:58 <SamSmith> q-
15:11:06 <pam> JoeAndrieu: wants it to be explicit in the did document as one piece of redundancy that can be checked
15:11:28 <pam> JoeAndrieu: resolver needs to know where to get it
15:11:40 <pam> brent: recipient needs to know where the resolver got it
15:11:56 <pam> burn: this may simplify down to did, did doc and resolver
15:12:37 <oliver> q-
15:12:42 <Justin_R> q
15:13:05 <pam> ChristopherA: could we just capture one line - person who submitted and the name of the property for all people still in the queue
15:13:25 <oliver> btw. additional properties for capabilitiesInvocation, attestationMethod, i.e., proof purposes, was already noted in https://github.com/w3c/did-core/issues/154
15:14:08 <pam> brent: apologies to those who have not been heard yet
15:14:31 <pam> ... we would like this process to continue, google slides may not be the format moving forward
15:14:44 <pam> ... can we move our content to a google doc for additional collaboration
15:14:53 <pam> JoeAndrieu:
15:15:21 <pam> ...: before we move anything, create a new section so that people who are in the queue can type in their proposed properties so they don't forget
15:15:33 <pam> ... creating additional slide  220
15:15:56 <pam> brent:  who will oversee the next steps here:  ChristopherA volunteers
15:16:39 <pam> markus_sabadello: want to ask one thing about requested content type:  this is more like an input option to the resolver - is this in scope?
15:16:47 <pam> brent: this is a determination to be made later
15:17:03 <pam> markus_sabadello: if this is a good property I have a whole list of such things
15:17:26 <pam> brent: if you are unsure at all where this goes, throw it in the doc
15:17:49 <pam> JoeAndrieu: there is confusion over what should go in the resolver or not - is it just a did doc before properties?
15:18:30 <pam> burn:  next steps recap:  get the properties into the slides, ChristopherA will pull that into a google doc and will invite people to add more
15:19:05 <pam> markus_sabadello: call the title "not-yet-discussed" not self-issued properties (re slide 220)
15:19:39 <juan_caballero> scribe+
15:19:55 <juan_caballero> brent: DID resolution process discussion
15:20:00 <manu> Topic: DID Resolution
15:20:16 <ken> ken has joined #did
15:20:18 <juan_caballero> ...: goal is clarity of role of resolution, are other inputs or outputs possible, etc
15:20:28 <manu> q+ to note that DID Resolution is great, and making great strides... but we shouldn't pull the spec in because we have a lot to do.
15:20:30 <Justin_R> q+ to discuss how important I see this is
15:20:40 <drummond> q?
15:20:41 <manu> q- later
15:20:45 <drummond> q+
15:20:58 <juan_caballero> burn: w3c process slows down combining or crossing groups, so we have to gather inputs and thoughts here but can't promise WG charter rewrites or mergers
15:21:07 <brent> q?
15:21:13 <SamSmith> q+
15:21:25 <brent> ack markus_sabadello
15:21:36 <juan_caballero> markus_sabadello: i think there's a lot of overlap between matrix parameters and DID resolution and properties relevant to both
15:21:56 <juan_caballero> ...: representations and registries also depend on resolution assumptions
15:22:08 <juan_caballero> ...: experience of VC WG lead us to this division of labor, but here
15:22:16 <juan_caballero> ...: it is harder to divide and abstract ]
15:22:38 <brent> ack Justin_R
15:22:38 <Zakim> Justin_R, you wanted to discuss how important I see this is
15:22:43 <juan_caballero> ...: these are arguments for aligning the efforts more closely, whether that means merging or just periodic checkins or other forms of integration
15:22:51 <juan_caballero> justin_r: i see a 3part stack here
15:23:44 <juan_caballero> ...: 1:  2: resolution process that produces a DIDDoc, 3: ; resolution isnt method-specific, it is constrained by a data contract between dids and diddocs;
15:24:08 <juan_caballero> ...: i think from tech standpoint it's essential to define that contract early on
15:24:19 <JoeAndrieu> q+
15:24:24 <juan_caballero> ...: we've had a lot of problems in last few months because each of us defines resoltuion differently
15:24:32 <SamSmith> +1 Justin and Markus
15:24:46 <gannan> +1 for defining the interfaces for resolution
15:24:49 <brent> +1 to resolution being a black box and that isn't great
15:24:49 <juan_caballero> ...: work isn't independent of this! this is a very normative dependency
15:24:59 <brent> ack manu
15:24:59 <Zakim> manu, you wanted to note that DID Resolution is great, and making great strides... but we shouldn't pull the spec in because we have a lot to do.
15:25:15 <JoeAndrieu> q+ to mention result type as a interface challenge between DID Core and DID Resolution
15:25:19 <juan_caballero> ...: 1 did 2 resolution 3 did doc
15:25:30 <juan_caballero> Manu: i agree with markus and justin's points\
15:25:38 <brent> q?
15:25:49 <Justin_R> q+ to talk about feature freezde
15:25:58 <juan_caballero> ...: i am opposed to officially bringing in other groups because it could really kill the feasibility of our feature freeze timeline
15:26:26 <juan_caballero> ...: we need to take those conversations into account non-normatively, and not let w3c process get in the way, but -1 for working on the spec in this group, we're too busy as it is
15:26:27 <brent> q+ to say what our options are if we pull in resolution
15:26:32 <brent> ack drummond
15:26:53 <juan_caballero> drummond: i have to respectfully disagree with my fine colleague Manu because I agree with Markus and Justin that we have major discrepancies in our concept of resolution
15:26:58 <juan_caballero> ...: i am still confused by the sandwiches!
15:27:36 <brent> ack SamSmith
15:27:39 <juan_caballero> ...: it's not in scope to define what resolution has to do, but actually, if spec defines valid methods, I think we DO have to define exactly what a method has to do in resolution!
15:27:40 <burn> q+ to talk IPR
15:27:42 <manu> q+ to note that we can always recharter when we're successful, we don't get to recharter if we're not successful.
15:28:04 <juan_caballero> SamSmith: i tried to resolve an ambiguity/discrepancy in the spec, and i couldn't until spending time in the other group!
15:28:29 <Justin_R> +1 to Sam's point, this is much what I wanted to add
15:28:29 <burn> q+ to ask what will actually make us faster
15:28:38 <juan_caballero> ... I also disagree with Manu, it will take more time, not less, to allow DID Resolution conversation to happen in parallel!
15:28:47 <juan_caballero> ... we should have a sandwich
15:28:56 <oliver> oliver has joined #did
15:28:57 <oliver> present+ oliver_terbu
15:28:59 <oliver> q+
15:28:59 <brent> ack JoeAndrieu
15:29:01 <Zakim> JoeAndrieu, you wanted to mention result type as a interface challenge between DID Core and DID Resolution
15:29:11 <juan_caballero> JoeAndrieu: wrt W3C mess, I don't want to comment; but wrt the cool guys samsmith and drummond ... i'm with them
15:29:47 <juan_caballero> ... the right steps in the right order reduces the time needed to do the work; extensibility conversation and resolution conversation are intimately dependent!
15:30:06 <brent> ack Justin_R
15:30:06 <Zakim> Justin_R, you wanted to talk about feature freezde
15:30:12 <markus_sabadello> q+
15:30:17 <juan_caballero> Justin_R: I agree with Drummond and Joe that it will actually go faster
15:30:54 <brent> ack brent
15:30:54 <Zakim> brent, you wanted to say what our options are if we pull in resolution
15:32:17 <juan_caballero> (process conversation)
15:32:37 <Justin_R> q+ to ask if we can normatively reference a Note from the recommendation
15:32:46 <juan_caballero> ivan: the fact of publishing a note during the lifetime of this group reinforces our [future] request to extend lifetime/charter
15:32:47 <Justin_R> q-
15:32:55 <brent> ack burn
15:32:55 <Zakim> burn, you wanted to talk IPR and to ask what will actually make us faster
15:33:26 <juan_caballero> burn: this wouldn't be an extension, it would be a recharter with new IPR issues and need new signature
15:33:51 <juan_caballero> ... resolution is in the [API/ transport layer] danger zone of blockers from outside
15:34:36 <juan_caballero> ... broader question: what would make us faster? if it's the same people doing the work, i would say keep proposing; what is it that is actually slowing down communication between groups
15:34:38 <Justin_R> q+ to ask if we could start to require the DID WG people to join the DID Res calls
15:34:42 <JoeAndrieu> q+
15:34:42 <brent> ack manu
15:34:44 <drummond> q+
15:34:44 <Zakim> manu, you wanted to note that we can always recharter when we're successful, we don't get to recharter if we're not successful.
15:34:56 <SamSmith> q
15:34:58 <juan_caballero> Manu: not a matter of if but when
15:35:06 <SamSmith> q+
15:35:09 <brent> zakim, close the queue
15:35:09 <Zakim> ok, brent, the speaker queue is closed
15:35:40 <juan_caballero> ... I think the same people will be doing the work if it's pulled in, PLUS i would lose a spec editor in the process
15:35:59 <juan_caballero> ... if someone new without a full plate took it on, that would help, but ...
15:36:13 <juan_caballero> ... isnt it just a subset of the people on that call? where's the communication problem?
15:36:31 <juan_caballero> ... (the same people in this WG i mean)
15:36:33 <drummond> q?
15:36:50 <brent> ack oliver
15:36:53 <juan_caballero> ... as for rechartering, demonstrating success is a much better foundation for rechartering than not having accomplished original goals
15:36:55 <gannan> What happens if the re-chartering process fails burn?
15:37:24 <juan_caballero> Oliver_terbu: I agree with drummond that bringing resolution in is LOGICAL , although I can't speak to the politics/process issues
15:37:55 <juan_caballero> brent: from charter: "we will determine relationship between identifier and resolution process"
15:37:58 <brent> q?
15:38:03 <juan_caballero> ... so i think the contract is in scope for us
15:38:04 <brent> ack markus_sabadello
15:38:11 <manu> q+ to note why it's out of scope.
15:38:16 <burn> If the rechartering process fails, gannan, the group does not continue beyond its original charter end date
15:38:24 <juan_caballero> Justin_R: I wrote that line! this contract was exactly what i meant, which is why i am so confused that the scope has changed
15:38:36 <juan_caballero> markus_sabadello: I think the resolution group follows this group closely but not vice versa
15:38:47 <Justin_R> s/the scope has changed/that resolution wasn't in scope (which I assumed it was)/
15:39:10 <brent> q?
15:39:15 <juan_caballero> ... changing division of labor between documents is not my goal, i think it would be counterproductive, i just think corespec and resolutionspec need to be aligned sooner/along the way
15:39:18 <brent> ack Justin_R
15:39:18 <Zakim> Justin_R, you wanted to ask if we could start to require the DID WG people to join the DID Res calls
15:39:26 <juan_caballero> ... writing about resolution in core spec seems confusing and counterproductive
15:39:39 <juan_caballero> Justin_R: one-way communication comment is accurate and i agree that it is a real problem
15:40:01 <ChristopherA> q+ to request that we don't lock out single method resolvers
15:40:11 <juan_caballero> ... it would be possible to write in a more black-box way about resolution in the core spec,
15:40:53 <juan_caballero> ... IF we had more clarity on the inputs and outputs of that black box-- particularly if there are other types of requests or other docs.
15:41:43 <brent> ack JoeAndrieu
15:42:19 <juan_caballero> JoeAndrieu: clarifying communication and scope problem:
15:42:26 <brent> zakim, open the queue
15:42:26 <Zakim> ok, brent, the speaker queue is open
15:42:27 <brent> q+
15:42:28 <brent> zakim, close the queue
15:42:29 <Zakim> ok, brent, the speaker queue is closed
15:43:01 <brent> ack drummond
15:43:07 <juan_caballero> ... Markus has already been lost to the other group, and that group will still work with same autonomy, we just need some kind of permission to talk about (and gain clarity about) their parallel work
15:43:36 <juan_caballero> Drummond: I wanna get back to king solomon
15:43:52 <juan_caballero> ... when I saw the line Justin added to the charter, it didnt surprise me, I always saw the sandwich
15:44:00 <manu> For the record, I have more to say about this, but we're running out of time and won't be able to get to it.
15:44:19 <juan_caballero> ... by which i mean, i always understood resolution was a contract within scope, whether it was happening elsewhere or not
15:44:37 <gannan> +1
15:44:47 <brent> +1
15:44:57 <manu> -1, not clear we "have" to do the contract.
15:44:58 <brent> ack SamSmith
15:45:03 <juan_caballero> ... we need to clarify what will go into that other spec or spec-like appendix/thing, and be in dialogue with the people writing it
15:45:08 <manu> q+
15:45:34 <juan_caballero> SamSmith: we don't know what we're allowed to do in the resolution; the draft spec is ambiguous on what we can do
15:45:59 <brent> ack brent
15:46:06 <juan_caballero> ... the user "does" resolution in parts of the spec, but we are so murky on the user's options that writing use cases is pretty shaky and hard to do accurately!
15:46:51 <juan_caballero> brent: not a new deliverable, but a PR for some kind of internal working document clarifying some of this would be within scope
15:46:53 <drummond> q?
15:47:48 <ivan> Topic: Ending Stuff
15:47:59 <juan_caballero> ... any contract (except one that bans single-method/internal resolvers) would be a helpful thing to PR and draft internally
15:48:01 <ChristopherA> The google doc to continue discussion of DID Doc/metadata/etc. Properties
15:48:01 <ChristopherA>  https://docs.google.com/document/d/1WoHIA5MzC-kKdyS3XVp5qT-ZiNUbpqXH59g3Q9Fnk04/edit?usp=sharing
15:49:18 <brent> zakim, open the queue
15:49:18 <Zakim> ok, brent, the speaker queue is open
15:50:33 <ivan> rrsagent, draft minutes
15:50:33 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html ivan
15:51:22 <juan_caballero> (logistics and feedback and planning)
15:54:24 <ChristopherA> BTW, I have posted my slides on "SSI: Bleeding Edges" https://docs.google.com/presentation/d/1BbkBX-tUgifiS_VKcqCZYRTQAGF5pK-JEYQwmHYbMcI/edit#slide=id.g442085c4c7_0_546 and video is at https://youtu.be/WlDSMRb_X-s
15:56:48 <markus_sabadello> https://www.w3.org/wiki/TPAC/2020
16:02:37 <ivan> zakim, end meeting
16:02:37 <Zakim> As of this point the attendees have been burn, ivan, gannan, ewelton, yoshiaki, brent, identitywoman, Joachim, Eugeniu_Rusu, manu, Justin_R, dezell, markus_sabadello, ken,
16:02:40 <Zakim> ... tplooker, charles, selfissued, drummond, nicole, to, ask, about, headers, v, URL, parameters, AND, what, are, these, NECESSARY, for?, yancy, JoeAndrieu, oliver, Juan_caballero,
16:02:40 <Zakim> ... pamela, ChristopherA, SamSmith, oliver_terbu
16:02:40 <Zakim> RRSAgent, please draft minutes
16:02:40 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html Zakim
16:02:42 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:02:46 <Zakim> Zakim has left #did
16:02:53 <juan_caballero> thanks everyone
16:02:59 <ivan> rrsagent, draft minutes
16:02:59 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/31-did-minutes.html ivan
16:03:05 <ivan> rrsagent, bye
16:03:05 <RRSAgent> I see no action items