-
Notifications
You must be signed in to change notification settings - Fork 14
/
Copy path10Dec2018.html
1883 lines (1882 loc) · 92.1 KB
/
10Dec2018.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0" />
<title>Strong Authentication and Identity Workshop -- 10 Dec
2018</title>
<link type="text/css" rel="STYLESHEET" href=
"https://www.w3.org/StyleSheets/base.css" />
<link type="text/css" rel="STYLESHEET" href=
"https://www.w3.org/StyleSheets/member.css" />
<link type="text/css" rel="STYLESHEET" href=
"https://www.w3.org/StyleSheets/member-minutes.css" />
<link type="text/css" rel="STYLESHEET" href=
"https://www.w3.org/2004/02/minutes-style.css" />
<meta content="Strong Authentication and Identity Workshop" name=
"Title" />
<meta charset="utf-8" />
</head>
<body>
<p><a href="http://www.w3.org/"><img src=
"https://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
"48" width="72" /></a></p>
<h1>- DRAFT -</h1>
<h1>Strong Authentication and Identity Workshop<br />
10 Dec 2018</h1>
<p><a href=
'https://www.w3.org/Security/strong-authentication-and-identity-workshop/schedule.html'>
Agenda</a></p>
<h2><a name="attendees" id="attendees">Attendees</a></h2>
<div class="intro">
<dl>
<dt>Present</dt>
<dd>Manu_Sporny(remote), Shigeya_Suzuki, achughes,
Dan_Burnett, hober, jfontana, jeffh, Brent_Zundel,
markus_sabadello, weiler, aaronpk, kimhd, JoeAndrieu,
oliver_terbu</dd>
<dt>Regrets</dt>
<dd></dd>
<dt>Chair</dt>
<dd>Wendy_Seltzer</dd>
<dt>Scribe</dt>
<dd>manu</dd>
</dl>
</div>
<h2>Contents</h2>
<ul>
<li>
<a href="#agenda">Topics</a>
<ol>
<li>
<a href="#item01">Introduction to Workshop</a>
</li>
<li>
<a href="#item02">Understanding Verifiable
Credentials</a>
</li>
<li>
<a href="#item03">Decentralized Identifiers</a>
</li>
<li>
<a href="#item04">Understanding DID Auth</a>
</li>
<li>
<a href="#item05">WebAuthn, CTAP</a>
</li>
<li>
<a href="#item06">FIDO and Authenticators</a>
</li>
<li>
<a href="#item07">und06 - Understanding JWT/CWT, OpenID,
and Related Ecosystemerstanding</a>
</li>
<li>
<a href="#item08">Indie Auth: OAuth for the Open Web</a>
</li>
<li>
<a href="#item09">Breakout Sessions</a>
</li>
<li>
<a href="#item10">Report-out from breakouts</a>
</li>
<li>
<a href="#item11">Market Verticals: Current and Future
Challenges</a>
</li>
<li>
<a href="#item12">Health Care IDology</a>
</li>
<li>
<a href="#item13">Law and DIDs</a>
</li>
<li>
<a href="#item14">The Enterprise</a>
</li>
</ol>
</li>
<li>
<a href="#ActionSummary">Summary of Action Items</a>
</li>
<li>
<a href="#ResolutionSummary">Summary of Resolutions</a>
</li>
</ul>
<hr />
<div class="meeting">
<h3 id="item01">Introduction to Workshop</h3>
<p class='irc'><<cite>scribe</cite>> scribe: manu</p>
<p class='phone'><cite>wseltzer:</cite> Hi, my name is Wendy
Seltzer, W3C - glad to welcome you here.<br />
... Thank you to Tony Nadalin and Microsoft for hosting
us.<br />
... We're looking forward to the next two days of discussion,
brainstorming, and socializing around Strong Auth and
Identity.</p>
<p class='phone'>Tony N. covers location of emergency exists,
bathrooms, and parking. Assistance help, medical emergencies
help, etc.</p>
<p class='phone'><cite>wseltzer:</cite> Very briefly,
introducing the day and goals of the workshop at a high level -
logistics, getting conversation going, etc.<br />
... We use IRC for realtime minuting and discussion... to
connect to the wifi - MSFT Guest and use the code on the
board.</p>
<p class='irc'><<cite>jeffh</cite>> :)</p>
<p class='phone'><cite>wseltzer:</cite> We are thrilled to have
everyone here - just a quick intro to W3C - our goal is to lead
Web to its full potential... we work on voluntary consensus
standards.<br />
... We put workshops like this on to bring people together,
lots of work is happening here and outside of W3C - if we can
be a forum for conversation, great, if it happens elsewhere,
great.<br />
... We are not the exclusive endpoint of work, but one possible
place to bring that work.<br />
... We are committed to Web for All.<br />
... We operate under Royalty-Free patent policy - this workshop
is not Recommendation track, contributions here ar enot yet
contributions that are goverened by patent policy. Our goal is
that specs should be implementatable RF wrt. patents /
copyright, etc.<br />
... We are a member consortium, we depend on members to
participate - hope to keep that infrastructural work going -
475 members from all sorts of places.<br />
... We operate workshops under a code of ethics and
professional conduct - if anyone has an issue, find wseltzer or
someone else in W3C Team. We want to make sure this environment
enables everyone to feel safe, respected and heard.<br />
... We are working in difficult areas, standards work well for
technical problem, good enough technical problem, and find a
common resolution.<br />
... This all depends on you and the broader community to make
sure these things work effectively.<br />
... We want to hear from everyone - you have cards, on those
cards, you can write down questions/comments/concerns - we will
use those to fill into Q/A and discussion that follows... we
will also have dots for voting, mark areas of particular
interest/concern.<br />
... We will have breakout sessions where we are gathering in
smaller groups... W3C process for consensus ... these are
preliminary directions/ideas... feel free to toss out ideas,
but don't worry that if you're not in a group that you're going
to miss the opportunity to provide critical input.<br />
... Also another part of getting together is social - Tony has
found us space in a nearby on campus restaurant.<br />
... This is pay your own way, but pay your own way... ~$20
minimum - interested and expecting to come tonight?</p>
<p class='phone'><cite>tony-tr:</cite> There is good
beer/wine.</p>
<p class='phone'><cite>wseltzer:</cite> Does anyone need a
shuttle?</p>
<p class='irc'><<cite>aaronpk</cite>> looks like all
hands raised except a few</p>
<p class='irc'><<cite>kenrb</cite>> almost everyone
raised hands</p>
<p class='phone'><cite>tony-tr:</cite> I'll get a couple of
shuttles.</p>
<p class='phone'>Scribe notes roughly 60+ people raised their
hands.</p>
<p class='phone'><cite>wseltzer:</cite> You can make off the
record statements... let us know if you want something to be
off the record.<br />
... We can do queue management via q+<br />
... We can capture what's going on at workshop... everyone is
capable of adding things to minutes.</p>
<p class='irc'><<cite>chrisboscolo</cite>> sorry you
can't be here in person, Manu!</p>
<p class='phone'><cite>wseltzer:</cite> Thanks to the PC and
Manu and the rest of the PC for putting all of this
together.<br />
... Thanks to Tony and Microsoft for hosting us here... our
goal is to move things quickly. Please add slides to google
slide deck.<br />
... You can email me to put material on Google Slide
deck...</p>
<p class='phone'><cite>Kaliya:</cite> Hi, passed around cards
to all of you - purpose of the workshop is to build mutual
understanding across strong auth and identity projects, to do
that, we're trying to gather as much input as possible.<br />
... We want to find potential connections between your work and
work being presented.</p>
<p class='phone'>Slide Directory for presentations -- <a href=
"https://drive.google.com/drive/folders/1Oldmw0i1NKhJJwKflG4X9egqP6LLySA2">
https://drive.google.com/drive/folders/1Oldmw0i1NKhJJwKflG4X9egqP6LLySA2</a></p>
<p class='phone'><cite>Kaliya:</cite> We want questions,
concerns, connections that you're seeing - we'll collect them
after each of 7 presentations, we want to get a sense of the
room about each of these.<br />
... Please put number on the card, and questions/concerns --
this can be made anonymously.<br />
... We will collect them after each presentation.</p>
<h3 id="item02">Understanding Verifiable Credentials</h3>
<p class='phone'><cite>burn:</cite> We are going to go through
this quickly, this is a quick overview.<br />
... When we talk about VCs, what do we mean by that?</p>
<p class='phone'><cite>Slides:</cite> <a href=
"https://docs.google.com/presentation/d/11hm-ajsLzroPmA-BcC2TryqAhKsF3jZ_wxHDnyUi_pg/edit">
https://docs.google.com/presentation/d/11hm-ajsLzroPmA-BcC2TryqAhKsF3jZ_wxHDnyUi_pg/edit</a></p>
<p class='phone'><cite>burn:</cite> There are all sorts of
things we use today quite successfully - we wanted to duplicate
that in an electronic form.<br />
... We would show age/drivers license -- we're switching to
education credentials - diplomas for example.<br />
... Diploma is interesting... I have PhD from Oregon, which was
acquired by another school... that school doesn't exist
anymore... that org might not exist anymore in any form... we
want to make sure we cover use cases like that... we are
interested in cryptographically verifiable credentials.<br />
... The work on VCs are just on a data model, not on protocol
yet... issuer/verifier -- we don't define ecosystem
normatively, but it's hard to talk about this w/o suggesting an
ecosystem.</p>
<p class='phone'>Slide 3</p>
<p class='phone'><cite>burn:</cite> When we talk about
Verifiable credentials... issuer issues to holder... holder
holds on to it... verifier asks for credential from
holder.<br />
... In this model, a VC contains credential metadata, claims,
and proofs... the identifiers can be cryptographically
controllers, but issuers can also be identified.</p>
<p class='irc'><<cite>achughes</cite>> burn: the verifier
is the one seeking verification</p>
<p class='phone'><cite>burn:</cite> What is a claim - one
statement about a subject, Pat is over 21, for example.</p>
<p class='irc'><<cite>wseltzer</cite>> i|welcome you
here|<a href=
"https://docs.google.com/presentation/d/1U5ArEC6lyZ5AS3UYiaKrO-fcXJuCcbE2A7JTjIGaKQA/edit?usp=sharing">Intro
slides</a></p>
<p class='phone'><cite>burn:</cite> Here's an example in
JSON-LD Syntax... we are defining a data model, and showing how
you can use different syntaxes...<br />
... At some point there is a realization of the syntax... the
main thing I want you to see is that there is an ID for the
credential, there is some type information... from perspective
of user... they are just using ProofOfAgeCredential... etc...
we have an issuer field, when it's issued, the part in red is
the actual claim.<br />
... We used to call this a "claim"... now we call this the
"credentialSubject" - the id represents the subject of the
claim... the property is ageOver and the value is 21.<br />
... There is a proof... the details don't matter... there is
just a proof on there... we do have some suggestions on
cryptographic proofs, but lots of this is
flexible/variable.<br />
... We also talk about presentations... issuer, holder,
verifier - it's actually a verifiable presentation by holder to
verifier... it's for multiple credentials, often about same
subject... identifier, some metadata, claims or some whole
credentials... main idea w/ presentation is something that
holder can pull from multiple credentials.<br />
... What are verifiable credentials and what are they not?</p>
<p class='phone'>Slide 8</p>
<p class='phone'><cite>burn:</cite> VCs allow an issuer provide
a statement of fact... holders hold on to them, verifier can
see if the statement hasn't been tampered with.<br />
... VCs don't represent verified truth... just who claimed
what</p>
<p class='phone'>Slide 9</p>
<p class='phone'><cite>burn:</cite> This work is being
standardized right now in VCWG... in scope is data model and
syntaxes...<br />
... We are looking at JSON-LD... and JWT...<br />
... We do not have browsers in scope... we do not define
protocol... we don't address "Identity on the Web"... we're
just providing VCs.<br />
... out of scope work could be chartered in future WG...
Credentials CG is looking at these items...<br />
... We have a spec, we're tryign to wrap up ZKP and JWT
support... we have done some Horizontal Review (non official...
expecting CR very soon.<br />
... We have test suites, use cases... (slide 10)<br />
... If you are curious about use cases... take a look at use
cases document...<br />
... Details of pictures are W3C Member Confidential... in
commerce, there are governments, banks, large websites, usign
VCs.<br />
... In trade, DHS, CBP, Canadian Provinces... importer,
exporter, etc. are some target use cases... real adoption
here.</p>
<p class='phone'>slide 13</p>
<p class='phone'><cite>burn:</cite> Are there questions?</p>
<p class='irc'><<cite>wseltzer</cite>> dirk_balfanz</p>
<p class='phone'><cite>dirk_balfanz:</cite> If you are conerned
w/ data model - some credential, over 21, you want to know if
*I* am over 21...</p>
<p class='phone'><cite>burn:</cite> There is plenty of
discussion around subject != holder.</p>
<p class='phone'><cite>JoeAndrieu:</cite> Use Cases talk about
that use case - we are looking at things that are out of scope
in protocol... but important to get a holistic view of
things.</p>
<p class='phone'><cite>burn:</cite> Anyone can make any claim
about anything... if you look at the ID in red, that's a DID,
this is where you may start seeing use for DIDs.<br />
... Control over the identifier is an interesting question
we're going to hear about soon...</p>
<p class='phone'><cite>tony:</cite> In looking at the current
spec, it still looks like JSON-LD is the language, it looks
like you're going to wrap regular JSOn or other types of
JWTs/CWTs - get a little concerned... those get quite large,
little concerned around size of expression.<br />
... We're not looking for just users making these statements,
we're looking for devices... concerned around size of
claims.</p>
<p class='phone'><cite>burn:</cite> Is that a question or
statement?<br />
... I'm not going to talk about the merits of one format of the
other... as a Chair, we have been asking for feedback from
others for the entire lifetime of WG... we do have people
looking at other formats.<br />
... We do have folks that are looking to support other
expression formats.</p>
<p class='phone'><cite>Oliver:</cite> We have a pull request in
for JWTs - we do have some shorter expression avoid duplication
in JSON-LD... issuer could become iss field.</p>
<p class='irc'><<cite>kimhd</cite>> Minutes and PR:
<a href=
"https://www.w3.org/2018/11/19-vcwg-minutes.html">https://www.w3.org/2018/11/19-vcwg-minutes.html</a></p>
<p class='irc'><<cite>kimhd</cite>> <a href=
"https://github.com/w3c/vc-data-model/pull/267">https://github.com/w3c/vc-data-model/pull/267</a></p>
<p class='phone'><cite>burn:</cite> We have welcomed
participation, we would like more input... we'd like help
wrapping up what we have... additional proposals to
recharter.</p>
<p class='phone'><cite>Sarah_Squire:</cite> Proposal in
Ethereum community ERC725 - are you working w/ them.</p>
<p class='irc'><<cite>Zakim</cite>> manu, you wanted to
note that we're trying to be agnostic.</p>
<p class='irc'><<cite>wseltzer</cite>> manu: we're trying
to be agnostic. Lots of experiments underway</p>
<p class='irc'><<cite>wseltzer</cite>> ... the model has
proven to be flexible</p>
<p class='irc'><<cite>wseltzer</cite>> ... It's true that
some formats have big payloads that won't work for small
devices</p>
<p class='irc'><<cite>wseltzer</cite>> ... could be that
cwt or jwt work at different layers of the stack</p>
<p class='irc'><<cite>wseltzer</cite>> ... and licensing
has a bigger payload</p>
<p class='irc'><<cite>wseltzer</cite>> ... different
tools in the toolbox</p>
<p class='phone'><cite>wseltzer:</cite> Any further questions
for Dan Burnett.<br />
... We're building up modules, understanding different
components that are available - different places that they
might be useful. Think about incompatibilities... ways we can
work together.</p>
<h3 id="item03">Decentralized Identifiers</h3>
<p class='phone'>Slides are here -- <a href=
"https://docs.google.com/presentation/d/1BX8r1KoxvJSQIX3PtAOzOawirwBYyze9QlyIaAbBRrM/edit">
https://docs.google.com/presentation/d/1BX8r1KoxvJSQIX3PtAOzOawirwBYyze9QlyIaAbBRrM/edit</a></p>
<p class='phone'><cite>kimhd:</cite> Hi, I'm Kim, CTO of
Learning Machine - work in educational credentials... co-chair
of W3C Credentials CG - also DIF Steering Committee.<br />
... What is a DID? It's a new type of URl that is globally
unique, highly available, presistent, cryptographically
verifiable, and doesn't require a centralized admin.<br />
... In education use cases, we want the recipient of a
credential to be identified using a DID.<br />
... A DID is an identifier for a subject.</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 3]</p>
<p class='phone'><cite>kimhd:</cite> here we have did:x:123 as
the identifier for the subject.<br />
... What does a DID look like?</p>
<p class='phone'>slide 4</p>
<p class='phone'><cite>kimhd:</cite> we have a scheme "did:",
then "DID Method", then did specific string.<br />
... There are examples of what these look like at the bottom of
the page...<br />
... Globally unique identifier - in many of these cases, you
can self-create your identifier... prove that you control it,
no central admin can take it away from you.<br />
... Each DID Method must specify a set of mechanisms - Create,
Read, Update, Delete (aka revoke)</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 5]</p>
<p class='phone'><cite>kimhd:</cite> One critical part - DIDs
resolve to DID Documents - we have a Veres One identifier here
- document it resolves to - contains authentication mechanisms,
public key material, services...<br />
... markus_sabadello is goign to talk about that next... DID
Resolver is retrieving DID Document.</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 6]</p>
<p class='phone'><cite>kimhd:</cite> So, DIDs resolve to DID
Documents... let's look at specific DID resolution
process.<br />
... This is saying we're using the BTCR method spec, run it
through the universal resolver, produces a DID Document.<br />
... identifier tells you which block, which transaction, to
find the transaction in.<br />
... Resolver knows, per method spec, how to get information,
how to return this thing.<br />
... so, DID Document has keys, authentication, services,
signatures, timestamps.</p>
<p class='phone'>slide DID Document</p>
<p class='phone'><cite>kimhd:</cite> This document has been
incubated at RWoT and IIW, currently draft in W3C CCG,
protocols and prototypes at DIF, there is a DID Method
Registry, DID Auth, DID Resolver...<br />
... We'd like to discuss a DID Working Group at this
Workshop.</p>
<p class='phone'><cite>tonyn:</cite> What do you expect to
standardize?<br />
... There doesn't seem to be cross-blockchain interop... I need
different DIDs on every blockchain... who is going to run the
registry... concerned around transparency of resolvers...</p>
<p class='phone'><cite>kimhd:</cite> Interop first - that's the
big part... what's the content of the DID Document, that
describes how interop is possible...<br />
... DID Auth, for example, needs that document....</p>
<p class='phone'><cite>ChristopherA:</cite> There are a couple
of different issues here - DID authenticates DID DOcument,
strongly make claim about DID Document... that document can
contain other key material from other places... including keys
that are compatible with say a different blockchain w/
different proof formats, PGP keys in there, information that
lets you allow you to leverage FIDO.<br />
... There are things like sigma proofs, ZKPs, private keys in
one curve equivalent to private keys in antoehr group... it's
premature to pick a method, maybe at some point the market will
say there is one two or three that are dominate... but reality
now is that there are multiple DID methods.</p>
<p class='phone'><cite>kimhd:</cite> We are starting to
categorize DID Methods.. BTCR and IPLD are ones where, if you
are comfortable w/ using that technology, you can create them
and use them in some way... depending on registry
authentication, you can start using that now... truly
self-sovereign identifiers, I create them, no one can take them
away from me.<br />
... In other cases, private/permissioned blockchain, those
enable different properties - for example Guardian models...
batch registration of individuals... some depend on properties
of the blockchain itself... which use cases argue for which...
we don't do guidance yet, DIF may do that... W3C is not in that
role.<br />
... People will have those questions... you don't want to use
something on a blockchain that can't be rewritten... part of
strength of it, something we're getting feedback on
ecosystem.</p>
<p class='phone'><cite>tony:</cite> Who is going to run the
registry, how scalable is it, who would pick up the
registry</p>
<p class='phone'><cite>ChristopherA:</cite> We are talking
about the DID Registry - you can reserve the DID Method... not
a DID Registry.<br />
... The requirements to have a proposal are very small... as
you move up the scale of maturity, we will have requirements
for what you have to do to do that.</p>
<p class='irc'><<cite>shigeya__</cite>> BTCR DID Method
<a href=
"https://w3c-ccg.github.io/didm-btcr/">https://w3c-ccg.github.io/didm-btcr/</a></p>
<p class='phone'><cite>ChristopherA:</cite> We need to allow
for innovation right now... there is nothing that says one has
to support every DID method, for example... don't use BTCR
unless you need technology.</p>
<p class='phone'><cite>kimhd:</cite> We can come back to that -
would like to focus on breadth</p>
<p class='phone'><cite>Kaliya:</cite> This dynamic is also what
these cards are for<br />
... If you have thoughts/comments/questions - please write them
down on paper right now.</p>
<p class='phone'><cite>hober:</cite> Does the DID Method
registry just let people know what an unregistered method
is?<br />
... Is it relatively straightforward to serve static JSON and
hook into all of this?</p>
<p class='phone'><cite>kimhd:</cite> Yes, we can look into
examples.</p>
<p class='phone'><cite>Pete:</cite> If I wanted to add a new
DID, how do I get resolved?</p>
<p class='phone'><cite>kimhd:</cite> There are different
resolvers - which methods support they support is up to each
resolver... part of value is that each DID method and how you
perform its operations... write any resolver to note your test
case... it's not going to be prescriptive.</p>
<p class='phone'><cite>wseltzer:</cite> Thank you very much
Kim... next up... Markus to talk about DID Auth...<br />
... Keep questions and comments coming throughout two days
here...</p>
<h3 id="item04">Understanding DID Auth</h3>
<p class='phone'>Slides -- <a href=
"https://docs.google.com/presentation/d/1TSMW5hckaaaybpV9OVeNbWO1QE_OsMP3Pc3GovAfvjw/edit">
https://docs.google.com/presentation/d/1TSMW5hckaaaybpV9OVeNbWO1QE_OsMP3Pc3GovAfvjw/edit</a></p>
<p class='irc'><<cite>Loqi</cite>> Slides has -1 karma
over the last year</p>
<p class='phone'><cite>Markus:</cite> Hi, working in CCG and
DIF, and Sovrin... DID Auth is more of a concept rather than a
spec... makes a lot of sense to have a concept... DPKI for
DIDs... and what they enable.<br />
... Using a DID Resolver to authenticate - you have DID, you
have key material associated with that... control the
identifier... not about proving we're over the age of XYZ, we
just prove that we have control over a DID.<br />
... We worked on a paper around Rebooting the Web of Trust...
looked at DID Auth - Kim noted authentication.<br />
... Authentication block points to public key - who has control
of the DID? If you have public key information, you can know
that anyone that has private key is authenticated.</p>
<p class='irc'><<cite>wseltzer</cite>> [slide: DID Auth
Example Architecture]</p>
<p class='phone'><cite>Markus:</cite> This is one example for
uPort - web page - mobile app authentication...<br />
... With a mobile app, private key corresponding to DID, I can
provide response to QRCode - post it back to web page...
important, web page uses DID Resolver to find DID, then find
public key, then verify that the signature on the
authentication was signed correctly.<br />
... This is just one of the possible flows.<br />
... We tried to analyze this stuff - different scenarios /
different flows - there are many, so DID Auth isn't just one
thing... it's a family of things that are being explored.<br />
... There are many transports, HTTP, QR, etc....<br />
... There are many more flows... observation - we were able to
draw all of these flows where there are two parties... if we
look at traditional models, we usually have 3 parties... but
this one has 2.</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 7]</p>
<p class='phone'><cite>Markus:</cite> I control a certain
identifier - trust relying party - individual - all sorts of
different transports...</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 8]</p>
<p class='phone'><cite>Markus:</cite> There are also people
that are using different data formats internally... we will
reuse things, but as I said, DID Auth is not trying to come up
w/ a new authentication protocol... but reuse where
possible.<br />
... I have seen JWTs... we can also see JSON-LD VCs...
self-issued VC....<br />
... We have been thinking a lot about OIDC + DID... also
looking at WebAuthn + DID...</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 10]</p>
<p class='phone'><cite>Markus:</cite> We've done some initial
thinking - working w/ OpenID Connect protocol, where we use
self-issued OpenID ... one way this could be done is to have
personal openID connect provider... protocol could be used,
similar with WebAuthn... FIDO... could reuse that.<br />
... There are other experiments around DID-TLS, DID-based HTTP
Signatures... DID-based PGP... using DIDs in SSH.</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 11]</p>
<p class='phone'><cite>Markus:</cite> Some things to consider
for the workshop - how would a DID Auth relate to VC exchange
protocol?<br />
... Other DID Auth principles... We may want to meet some
principles, otherwise it's not DID Auth... for example,
identifier stays the same... rotate keys, change service
endpoints, change OID endpoints, authmethod, but we continue to
always be able to prove control of the same identifier.</p>
<p class='phone'><cite>wseltzer:</cite> Questions from the
room?</p>
<p class='phone'><cite>JohnB:</cite> I may beat Tony to some of
these questions ... In a number of the flows that you put up,
potentially they are a step backwards from a security
perspective because they're phishable... we need to make sure
we're not going backwards from a security perspective.<br />
... I would even step back a bit further and question - is the
use case for DID Auth actually authentication, or is it more
appropriately proving presentment of VCs.<br />
... We do have pairwise privacy preserving WebAuthn... even
Apple is deploying it... do we actually need to present
correlatable claim, or should we look at the best
mixture?<br />
... Some have said we need new authentication method when that
may not be the best path.</p>
<p class='phone'><cite>Markus:</cite> Lot of questions - let's
keep the benefits of existing things... not be phishable...
concept of DID Auth is that we have an identifier that cannot
be taken away from me, I can rotate keys, I can rotate metadata
out... I think OIDC or WebAuthn don't provide that out of the
box.</p>
<p class='phone'><cite>JohnB:</cite> The argument that you need
to rotate credentials is making presumptions about how they're
stored... I don't buy into the premise that a DID is required
because you need to rotate private keys, not arguing that there
are not use cases for DIDs, let's find the right use cases for
them.<br />
... For purely pairwise pseudonymous auth, I don't believe a
DID having a public key published is a requirement.</p>
<p class='phone'><cite>Daniel:</cite> A couple of things on the
business side (from Microsoft perspective)... would love it if
people used LinkedIn for everything (Microsoft property) -
Universities didn't really want to sign up to single entities,
because of corporate identifiers controlled by something other
than University.<br />
... So, there is a strong business use case for DIDs... large
entities that don't want other large entities to lock them in
via identifiers.<br />
... There are also use cases around progressive trust... you
start out pseudonymous, but then upgrade over time. For
example, FIDO doesn't cover the use case for expressing
services around DID Documents... granting access to my data
storage service.</p>
<p class='phone'><cite>Tony:</cite> I get concerned around
methodology for DIDs... you don't actually know if person that
created the key is doing the DID Auth itself... you can do this
in FIDO... authenticators is a drvice that you control. I'm not
seeing end to end comprehension of how you keep keys safe and
to the actual creator of the keys. How do you prove that
situation in DID Auth.</p>
<p class='phone'><cite>ChristopherA:</cite> I think part of the
problem here, we're overinflating the use of keys, for
simplicity purposes, you see DID Document up there - presuming
that private key is in a file some place...<br />
... That is a gross simplifciation, we can keep separate
keys... we don't call it a signature block, there might be a
variety of different types of proof... for example, if I issue
Verifiable Credential covering you for 1 million dollars... I
want a higher spec of authenticator/proofs before I give you
that verifiable claim.<br />
... DID Documents enable you to use all of this stuff... we
need people that have experience with these systems. All the
perils of mixing authn w/ authz... but at some point we need
something like a DID DOcument... just because someone asks for
a VC or other things, doens't mean I have to give it to
them/comply... or they have to accept.</p>
<p class='phone'><cite>Dirk:</cite> Where do you see DID and
DID Auth fit into the larger picture... I think I understand
VCs... I want to prove my age, SSN, I thought DIDs were a means
to an end...<br />
... One way I could do that, who are you?, I could provide DID
and DID Auth, prove that's who I am... find something in DID
Document, claim I'm over 21? Am I seeing that right... how is
DID connected to VCs?</p>
<p class='phone'><cite>Markus:</cite> We don't put VCs in
public ledgers...<br />
... DID Documents are for looking up key material and
services.... not VCs.<br />
... There are no claims in DID Document, only metadata required
to verify VC material...<br />
... DID Auth is just a high level concept so far...<br />
... No assumptions about documents are in ledger, where keys
are stored, where hardware wallets are... etc.</p>
<p class='phone'><cite>wseltzer:</cite> We have a queue... and
then break...</p>
<p class='irc'><<cite>wseltzer</cite>> JoeAndrieu: None
of these components yet is identity assurance</p>
<p class='irc'><<cite>wseltzer</cite>> ... the proof that
you are the person who can make these claims</p>
<p class='irc'><<cite>wseltzer</cite>> manu: it's not
either or</p>
<p class='irc'><<cite>wseltzer</cite>> ... we're trying
to combine elements of the prior art</p>
<p class='irc'><<cite>Zakim</cite>> manu, you wanted to
note FIDO + DIDs are complementary.</p>
<p class='irc'><<cite>wseltzer</cite>> ... authentication
flow that takes FIDO key material into a DID doc and uses HW
token to identify</p>
<p class='irc'><<cite>weiler</cite>> manu: I hear in this
discussion a perception of an either-or thing. the experiments
going on right now .... there is an auth flow that takes a FIDO
authenticator, puts the credentials in the DID document</p>
<p class='phone'><cite>JoeAndrieu:</cite> For VCs and DID and
DID Auth - none of those is sufficient for identity
assurance... whether the key is on a hard drive, or on a
hardware authenticator, we can't prove that person controlling
device is the person... it's a strong factor.</p>
<p class='irc'><<cite>weiler</cite>> ... There is a a lot
of work around blending these models rather than picking
one.</p>
<p class='irc'><<cite>oliver-terbu</cite>> +1 manu</p>
<p class='phone'><cite>markus_sabadello:</cite> We did quite a
bit of work around blending models at IIW.</p>
<p class='phone'>Everyone takes a break, socializing, expect to
get back into OpenID, JWT/CWT, etc. use cases.</p>
<p class='irc'><<cite>wseltzer</cite>> [break for
30min]</p>
<h3 id="item05">WebAuthn, CTAP</h3>
<p class='irc'><<cite>wseltzer</cite>> <a href=
"https://docs.google.com/presentation/d/1fiMFAw397cb2UPvywN4zCHCZtz_1tQsR0A6f5rpzoKw/edit?usp=sharing">
Slides, Modern Authentication</a></p>
<p class='irc'><<cite>inserted</cite>> scribenick:
wseltzer</p>
<p class='phone'>[slide 2:: How Security Keys Work]</p>
<p class='phone'><cite>JohnFontana:</cite> presenting
slides</p>
<p class='phone'>[slide 3: Registration]</p>
<p class='phone'><cite>JohnFontana:</cite> FIDO2 is an umbrella
term for WebAuthn and CTAP<br />
... CTAP at FIDO, WebAuthn at W3C</p>
<p class='phone'>[slide 4]</p>
<p class='phone'><cite>scribe:</cite> CBOR is the CTAP data
format</p>
<p class='phone'>[slide 5: WebAuthn]</p>
<p class='phone'><cite>scribe:</cite> create and get strong
authentication</p>
<p class='phone'>[slide 6]</p>
<p class='phone'>[slide 7]</p>
<p class='phone'><cite>scribe:</cite> Thanks to Pam for this
map</p>
<p class='irc'><<cite>Mitja</cite>> Can you please
reshare the link to the presentation?</p>
<p class='phone'>[slide 8: state of state]</p>
<p class='irc'><<cite>Mitja</cite>> thank you!</p>
<p class='phone'>[slide 9]</p>
<p class='phone'><cite>TonyNad:</cite> IETF discussion of
EAT<br />
... device attestation about provenance, devices,
ecosystem<br />
... we use these attestations in WebAuthn and FIDO to
understand key provenance and strength<br />
... you may not want to accept authentication from weak device,
TEE<br />
... At Prague IETF will probably try to form a WG<br />
... CWT, JWT for devices, compact<br />
... looking to do in generic way<br />
... data models for device, what type of device<br />
... indirect and direct attestations<br />
... want to be compatible with OAuth, JWT, CWT<br />
... use existing verification libraries</p>
<p class='irc'><<cite>ChristopherA</cite>> Queue is
closed</p>
<p class='phone'><cite>dirk:</cite> deliberately
lightweight<br />
... 2 party system: authenticator on client, relying
party<br />
... by design , the keypair I generate for e.g. Google, will
never be known to Github<br />
... roaming authenticators, keyfobs, will be
single-factor<br />
... second use case, bring touch ID, Windows Hello</p>
<p class='irc'><<cite>jeffh</cite>> scribenick jeffh</p>
<p class='phone'><cite>dirk:</cite> to the web platform</p>
<p class='irc'><<cite>manu</cite>> scribenick: jeffh</p>
<p class='phone'><cite>oliver-terbu:</cite> are there
implecations on the challenge itself?</p>
<p class='phone'><cite>john_bradley:</cite> challenge is
hashed, in clientdata you get orig back, ...</p>
<p class='phone'><cite>ChristopherA:</cite> how much of web
stack are part of webauthn spec? can things that are not
webservers leverage webauthn if they don't wanna leverage JS
stacks?</p>
<p class='irc'><<cite>brentz</cite>> ChristopherA: can
things that aren't web servers leverage Web Authn?</p>
<p class='phone'><cite>john_bradley:</cite> it depends, and OS
platform can impl webauthn-like APIs</p>
<p class='irc'><<cite>wseltzer</cite>> jeffh: WebAuthn
spec defines protocol between authenticator and relying
party<br />
...: are they webauthn-like? windows' platform webauthn api
is</p>
<p class='irc'><<cite>wseltzer</cite>> ... it can pass
through whatever stack is in the way</p>
<p class='phone'><cite>oliver-terbu:</cite> who is issueing
these EAT attstns? are they some kind of certifcation for the
authnr itself?</p>
<p class='phone'><cite>john_bradley:</cite> at momement
webauthn does not use eat attstn, we already have various
attstn formats, can add EAT if its approp, can't have too many
standards :)</p>
<p class='phone'>chris boscollo: what if authnr is loast and
one needs to re-register?</p>
<p class='phone'><cite>john_bradley:</cite> that's RP specific,
but thinking is that one has both roaming and platform authnrs
and one can use either or to re-register at the RPs</p>
<p class='irc'><<cite>weiler</cite>> ack \</p>
<p class='phone'><cite>tonynad:</cite> webauthn wg working on
this, one idea is to have a 'backup authnr' which allows one to
re-reg</p>
<p class='irc'><<cite>Zakim</cite>> ChristopherA, you
wanted to How about additional key types, in particular
secp256k1 used by bitcoin & ethereum</p>
<p class='phone'><cite>christophera:</cite> i have need for
tyupe of crypto that uses SECP-256 curve, how do we ensure how
we get those key flavors supported?</p>
<p class='phone'><cite>john_bradley:</cite> we already have alg
agility in the protocol, plus Mike Jones will be talking about
this in a few min....</p>
<p class='phone'>sam wieler: <missed question></p>
<p class='phone'>john fontana: <mumble></p>
<p class='phone'><cite>markus_sabadello:</cite> question wrt UX
eg if one registers a DID rather than a public key, can
leverage that in many ways.... thoughts?</p>
<p class='phone'><cite>john_bradley:</cite> in priciple, yes,
tho much to sort out there</p>
<p class='phone'>next speaker: Rae Hayward, fido</p>
<h3 id="item06">FIDO and Authenticators</h3>
<p class='irc'><<cite>wseltzer</cite>> [same slide
deck]</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 12]</p>
<p class='phone'>Rae's slides are in the '05 - Day 1 -
Understanding WebAuthn, CTAP, EAT, FIDO and Authenticators'
deck</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 15]</p>
<p class='irc'><<cite>wseltzer</cite>> Rae:
ROE=restricted operating environment</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 19:
Companion Programs]</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 20:
Labs]</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 21:
Expiration, derivative, and delta certification]</p>
<p class='phone'><cite>pamela:</cite> if a RP wants to accept
only authnrs of L3 certif, how do they do that?</p>
<p class='phone'><cite>rae:</cite> the certif level will be in
metadata, plus fidoalliance.org lists certified devices</p>
<p class='phone'>scott david: on the delta certif, when org
learns cetif'd device is now different, what happens. e.g., pci
"compensating controls", plus ecosystem feedback can be fed
back into spec development -- what about FIDO's processes?</p>
<p class='phone'><cite>rae:</cite> the security secretariat has
processes to notice such things and feed info into working
group....</p>
<p class='phone'><cite>PindarHK:</cite> can u tell which lab
did orig certif? <missed rest><br />
... can determine provenance of the lab that performed
certif?</p>
<p class='phone'><cite>rae:</cite> no, that's not public info,
do have internal mechs that would know this</p>
<h3 id="item07">und06 - Understanding JWT/CWT, OpenID, and
Related Ecosystemerstanding</h3>
<p class='phone'>Mike Jones presenting</p>
<p class='phone'>+ John_bradley</p>
<p class='irc'><<cite>wseltzer</cite>> <a href=
"https://docs.google.com/presentation/d/1XaCIGFCi4ILgXMzT3XUlSS51Vabb8-1gUGGpNCMD3D4/edit?usp=sharing">
Slides</a></p>
<p class='irc'><<cite>wseltzer</cite>> [slide 3]</p>
<p class='irc'><<cite>wseltzer</cite>> selfissued: (Mike
Jones) JSON Web Token</p>
<p class='phone'>[slide 4]</p>
<p class='irc'><<cite>tantek</cite>> speaker: "JSON-LD
requires canonicalization to RDF in order to sign" [interesting
I didn't know that.]</p>
<p class='phone'>[slide 5]</p>
<p class='phone'>[slide 6]</p>
<p class='irc'><<cite>manu</cite>> tantek -- well, no,
that's not correct...</p>
<p class='irc'><<cite>Loqi</cite>> tantek has -1 karma in
this channel over the last year (82 in all channels)</p>
<p class='phone'>[slide 6]</p>
<p class='irc'><<cite>manu</cite>> tantek, You can dump
JSON-LD in a JWT w/o needing
normalization/canonicalization.</p>
<p class='irc'><<cite>manu</cite>> tantek, if you want to
do LD-Proofs, then we have chosen that it's best to do RDF
Graph Canonicalization (the benefit being that you can have the
same signature expressed in a variety of different syntaxes w/o
having to recanonicalize)... so you sign the information.</p>
<p class='phone'>[slide 9]</p>
<p class='phone'>[slide 10]</p>
<p class='phone'>[slide 11]</p>
<p class='irc'><<cite>wseltzer</cite>> John_Bradley:
extensible. There's a set of core statements, and others can be
added</p>
<p class='phone'>[slide 12]</p>
<p class='irc'><<cite>wseltzer</cite>> selfissued: New
work. THose interested should talk to us and participate</p>
<p class='phone'><cite>selfissued:</cite> specifically the CBOR
web token (CWT)<br />
... RFC 8392</p>
<p class='irc'><<cite>wseltzer</cite>> John_Bradley:
complementary to webauthn, not competitive</p>
<p class='irc'><<cite>wseltzer</cite>> ... OpenID Connect
is about federated claims and API access</p>
<p class='irc'><<cite>wseltzer</cite>> ... should
probably use WebAuthn for authentication</p>
<p class='irc'><<cite>wseltzer</cite>> Chrisboscolo: how
do relying parties learn about self-issued identifiers?</p>
<p class='phone'><cite>chris_boscolo:</cite> wrt self-soverign
is there way for an individ to assert that they are speaking
for themselves?</p>
<p class='phone'>PeterWatkins aggregated claims? more about
that?</p>
<p class='irc'><<cite>wseltzer</cite>> <a href=
"https://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims">
https://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims</a></p>
<p class='phone'><cite>selfissued:</cite> if you search for
'openid claim' you can find it<br />
...: see above</p>
<p class='irc'><<cite>wseltzer</cite>> JackCallahan: How
does mobileconnect differ?</p>
<p class='phone'>JackCallahan what're differences between
mobile connect and openid connect</p>
<p class='phone'><cite>john_bradley:</cite> <describes
nuanced facets of the relationship></p>
<p class='phone'><cite>self_issued:</cite> gsma certified their
core impl with the openid connect certif suite</p>
<p class='phone'><cite>oliver:</cite> w3c VC WG is working on
JWT representation -- how <missed it> ?</p>
<p class='phone'><cite>selfissued:</cite> that's stuff we can
discuss</p>
<p class='phone'><cite>joeandrieu:</cite> can i use my own
crypto identifiers to make use of other's claims</p>
<p class='phone'><cite>selfissued:</cite> sure, that's an
aggregated claim....</p>
<p class='phone'><cite>john_bradley:</cite> the spec talks
about how that's done syntactically, it is work for the reader
as to how the relationships between the parties are actually
arranged and maintained<br />
...: you'd use some sort of proof-of-possess to logically tie
the claims together</p>
<h3 id="item08">Indie Auth: OAuth for the Open Web</h3>
<p class='phone'>aaron Parecki</p>
<p class='phone'>[slide 13]</p>
<p class='irc'><<cite>wseltzer</cite>> [slide 13 begins
AaronPK's presentation]</p>
<p class='phone'>[slide 14]</p>
<p class='phone'>[slide 15]</p>
<p class='phone'>[slide 16]</p>
<p class='phone'>[slide 17, 18, 19]</p>
<p class='phone'>[slide 20]</p>
<p class='phone'>[slide 21, 22]</p>
<p class='phone'>[slide 23]</p>
<p class='phone'>[slide 24]</p>
<p class='phone'>[slide 25]</p>
<p class='irc'><<cite>wseltzer</cite>> aaronpk: take
OAuth and add constraints</p>
<p class='phone'>slide 26]</p>
<p class='phone'>[slide 27,28,29]</p>
<p class='phone'>[29, 30]</p>
<p class='phone'>[slide 31]</p>
<p class='phone'><cite>pamela:</cite> how does client authn
piece of this work?</p>
<p class='phone'><cite>aaronpk:</cite> clidents are all ident'd
by URLs as well. instead of 'pre reg', it is just use the
domain name<br />
...: taking the idea of 'public clients' and extending it to
all clients</p>
<p class='phone'><cite>markus_sabadello:</cite> it is not
openid connect, it is oauth, why?</p>
<p class='phone'><cite>aaronpk:</cite> this is solving smaller
scoipe than OIDC -- is presenter of URL in control of
url?<br />
...: wrt webfinger, we are using HTTP link-rels and so is more
simple, dont see much use of webfinger in this</p>
<p class='phone'><cite>kaliya:</cite> how is this diff than
openid 1.0?</p>
<p class='irc'><<cite>tantek</cite>> "OpenID [1.0] only
solved half of that"</p>
<p class='irc'><<cite>tantek</cite>> "OpenID Connect went
away from solving that problem [users bringing their own
identity]"</p>
<p class='phone'><cite>aaronpk:</cite> is pretty similar.
openid connect drifted away. indieweb adds in api access tokens
to orig openid ideas</p>
<p class='phone'><cite>kaliya:</cite> what do after lunch,
invite room to chime in on what all we've heard this morning...
everyone gets a white card, question we want u to answer by end
of lunch is: from where you sit, what do you want to see happen
in terms of work in next 2..5 yrs; alternative question: what
is the biggest concern you have wrt what you heard this
morning?<br />
...: then we will get together in groups and sort through this,
and boil it down and discuss in the entire group.<br />
... your job for lunch is to answer one or both of the above
questions<br />
... only 30 min for lunch and question answering</p>
<p class='irc'><<cite>wseltzer</cite>> [lunch]</p>
<p class='irc'><<cite>inserted</cite>> scribenick:
manu</p>
<h3 id="item09">Breakout Sessions</h3>
<p class='phone'><cite>Kaliya:</cite> What you're going to do
in the groups... briefly say who you are, read out your card to
the group, ask clarifying questions.<br />
... Talk about concerns, each person has two votes to give to
two other cards... you're six people... you get to say "I think
that idea is really important, or that concern is really
important".<br />
... 12 votes in each circle.<br />
... You don't vote for your own card. :)<br />
... So, out of the six things, you get to pick your
favorite.<br />
... Don't vote twice for the same one.<br />
... Someone else might share your concerns, keep that in
mind.<br />
... You're going to be in a group of six, then discuss for 20
minutes, then scramble the room. talk to six new people, do the
same thing... find out whose card had the most votes on
it.<br />
... The point here is to get group intelligence to work... I
will track time, will check in with the groups... close
computers completely, groups gather, etc.<br />
... If you create new ideas, we'd love to hear about them.
Write them down.<br />
... Each card with a tally, any additional outputs, we're happy
to receive them.<br />
... If you came from the same company, you cannot be in the
same group. Six people in a group.</p>
<p class='phone'>Breakout sessions are forming... magic is
happening.</p>
<h3 id="item10">Report-out from breakouts</h3>
<p class='phone'><cite>Kaliya:</cite> First segment, we'll hear
all concerns... let's hear work items.</p>