Child pages
  • Meeting Minutes 5 June 2019
Skip to end of metadata
Go to start of metadata

Kantara FI-WG Teleconference

Approved by quorum on 2019-07-17 call

Date and Time

  • Date: Wednesday, June 5, 2019
  • Time: 16:30 EDT

Attendees

  • Roy, Nicholas (v),
  • Bush, Judith (v)
  • Cantor, Scott (v)
  • Buxey, Alan (v)
  • Morgan, Andrew (v)

Apologies

  • Hoehn, Walter (v)
  • Wessel, Keith (v)
  • Goodman, Eric

Agenda

  1. Roll call (QV group participation agreement - 5 of 9)
  2. Agenda bash
  3. Approval of previous meeting's minutes: https://kantarainitiative.org/confluence/x/2IDJBg
  4. Review of previous AIs:
    1. Walter: formatting revisions
  5. Review of feedback received so far: https://kantarainitiative.org/confluence/x/6IDJBg
  6. Broader community participation
    1. Note sent to the larger list as well as a couple of additional nudges sent by Colin and Rainer to specific groups.
    2. Are we making progress?
    3. Do we need to do more? If so, brainstorm additional channels.

Minutes

  1. Roll call
  2. Agenda bash -- no new topics
  3. No Quorum, therefore no minutes approval
  4. AI: Nick will ask Walter re formatting on the list [DONE]
  5. Discussion of open issues
    1. Scott needs to refresh his memory on the specs.
    2. RFC doesn’t really matter, that’s the underlying-underlying spec. It’s XML encryption that matters.
    3. There is a newer one that allows for more pluggability.
    4. AI: Scott to do some research on this and get back to the group
    5. OAEP is a pain, confusing, like six different algorithms floating around.
    6. Intent “Use the standard default function, don’t get fancy.”
    1. Issue #129 from github
  6. Minutes approved from last meeting
  7. Issue 1: contrast the two profile and reference other.
    1. No disagreements
    2. Would slot in after first paragraph
    3. AI: Nick will propose language
  8. Issue 2: Scott already has a comment
    1. 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.
    2. Scott says it’s hard to explain why the requirement is true in practice even if not in theory.
    3. 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.
    4. We should give examples that tie back to different ways that trust can be verified.
    5. 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.
    6. Let’s focus on a positive requirement -last sentence in italics.  We’ll need to turn it into a technical requirement
    7. AI: Scott will take this approach
  9. Issue 3: Ajax…. Single page apps
    1. AI: Andy will fix this one
  10. Issue 4: SP23
    1. NoOp - answered by Scott
    2. AI: Nick to ask Rainer to clarify [DONE]
  11. No thoughts on beating additional bushes for feedback --we have attracted some ….


Next Meeting

  • 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.

  • No labels