Kantara FI-WG Teleconference
Date and Time
- Date: Tuesday, June 6, 2019
- Time: 16:30 EDT
- Roy, Nicholas (v),
- Bush, Judith (v)
- Cantor, Scott (v)
- Buxey, Alan (v)
- Morgan, Andrew (v)
- Hoehn, Walter (v)
- Wessel, Keith (v)
- Goodman, Eric
- Roll call (QV group participation agreement - 5 of 9)
- Agenda bash
- Approval of previous meeting's minutes: https://kantarainitiative.org/confluence/x/2IDJBg
- Review of previous AIs:
- Walter: formatting revisions
- Review of feedback received so far: https://kantarainitiative.org/confluence/x/6IDJBg
- Broader community participation
- Note sent to the larger list as well as a couple of additional nudges sent by Colin and Rainer to specific groups.
- Are we making progress?
- Do we need to do more? If so, brainstorm additional channels.
- Roll call
- Agenda bash -- no new topics
- No Quorum, therefore no minutes approval
- AI: Nick will ask Walter re formatting on the list [DONE]
- Discussion of open issues
- Scott needs to refresh his memory on the specs.
- RFC doesn’t really matter, that’s the underlying-underlying spec. It’s XML encryption that matters.
- There is a newer one that allows for more pluggability.
- AI: Scott to do some research on this and get back to the group
- OAEP is a pain, confusing, like six different algorithms floating around.
- Intent “Use the standard default function, don’t get fancy.”
- Issue #129 from github
- Minutes approved from last meeting
- Issue 1: contrast the two profile and reference other.
- No disagreements
- Would slot in after first paragraph
- AI: Nick will propose language
- Issue 2: Scott already has a comment
- Scott explains other ecosystems may not have the issue, eg federated PKI or some other trust anchor, completely trusted CAs… There are other ways to do this but not relevant to R&E feds.
- Scott says it’s hard to explain why the requirement is true in practice even if not in theory.
- Can we have a nuanced response to Rainer? We do have italicised comments …. MUST NOT is “false” unless … we need to explain the metadata verification…. NO we do need to change this to be correct.
- We should give examples that tie back to different ways that trust can be verified.
- We can say must not if we preclude other ways. SWITCH might do something different? Some R&E feds do use different patterns, but it’s not the same issue as Reiner is bringing up. Since we are trying to avoid bringing up federations, we don’t want to preclude.
- Let’s focus on a positive requirement -last sentence in italics. We’ll need to turn it into a technical requirement
- AI: Scott will take this approach
- Issue 3: Ajax…. Single page apps
- AI: Andy will fix this one
- Issue 4: SP23
- NoOp - answered by Scott
- AI: Nick to ask Rainer to clarify [DONE]
- No thoughts on beating additional bushes for feedback --we have attracted some ….
- Date: Tues, June 19#, 2019
- Time: 16:30 EDT
- Code: https://global.gotomeeting.com/join/110596309
You can also dial in using your phone.
United States: +1 (669) 224-3318
Access Code: 110-596-309
More phone numbers
Australia: +61 2 8355 1038
Austria: +43 1 2530 22500
Belgium: +32 28 93 7002
Canada: +1 (647) 497-9380
Denmark: +45 32 72 03 69
Finland: +358 923 17 0556
France: +33 170 950 590
Germany: +49 692 5736 7300
Ireland: +353 15 360 756
Italy: +39 0 230 57 81 80
Netherlands: +31 207 941 375
New Zealand: +64 9 282 9510
Norway: +47 21 93 37 37
Spain: +34 932 75 1230
Sweden: +46 853 527 818
Switzerland: +41 225 4599 60
United Kingdom: +44 330 221 0097
NOTE: Do not follow the code with a "#" symbol as it may cause the code not to be recognized.