Kantara FI-WG Teleconference

...

Roll call (QV group participation agreement)
Agenda bash
Approval of 9/4 18 meeting minutes: https://kantarainitiative.org/confluence/x/rgbnBg
SAML2int formatting edits
Reiner’s comment on the feedback page: https://kantarainitiative.org/confluence/x/6IDJBg
Review of outstanding issues in Github
Implementation profile discrepancy about key encryption
Any further work needed on feedback received

Roll call “As of 21st August 2019, quorum is 4 of 7.”
Agenda bash: none
Minutes: Judith moves to approve the minutes; Keith seconds. Minutes are approved.
Action items for Eric and Alan last time: Eric’s AI is done (capitalization & normalization of browser profiles; consideration regarding an appendix but there may be language around SHA1 & SHA 2 - -Scott’s Action Item. Alan also had headings for contributors with color issues, resolved.
Reiner’s comment on the feedback page: https://kantarainitiative.org/confluence/x/6IDJBg -- Scott (and Judith) have not made progress
Eric confirms GitHub has no open issues, pull requests.
Discrepancy between deployment & implementation profile for SHA-1 & SHA-2 appears to be an errata on implementation profile. Colin sent an attachment describing the loose process for errata:

Simple flowchart
The Should in the document is a must in the XML & SAML Conformance document; we tried to make this document standalone to avoid confusion about some of the SAML conformance complexity.
SHA-1 was a SHOULD in the implementation profile and we would recommend it to be a MUST -- it is a MUST in XML encryption and SAML docs <<< Check this in the minutes review
AI: Keith will work with Colin to get this formally noted with the Kantara staff

Depending on how disruptive the Discovery changes are - hopefully less contentious -- thus we think this will be it.

Once we think we have consensus what is our next step? AI Keith will note in email to Colin we are almost ready for next steps: what are those?
Review of Scott’s edits to SDP-SP23 sent to the list on 10/15
Possible confusion around wording of SDP-G02 and Nick’s proposed change

Removing the reference was appropriate
Shorter - that seemed good
Not sure about references to other work so did not add any
Might want to consider changing the word ‘some’ to ‘most’ under discovery description.
Could put ‘in many cases’ and not try to quantify it
Less aspirational than a way of telling people that they’re doing it wrong.
Anyone unhappy with what’s been presented?
Scott would maybe rethink the wording in the normative requirement: We understand that it’s self-evident.
Implementation profile calls out idpdisco as a MUST
Seems like not a drop-able item, and wording seems good.
Wording complements the implementation profile.
No misgivings - we have rough consensus.
AI: Scott commit - DONE

...deployments MUST limit the size of each individual XML element's and attribute's text value they produce to 256 characters

References content rather than making it clear you’re talking about string content. “XML attribute content”
We have a recommendation
Hard to be confused by the existing wording
Discussion of which elements/attributes this applies to
IDP-19 caused similar confusion
This will be clearer if we are allowed to have FAQs. OASIS didn’t used to allow that.
To define versus to not define via xs:String. Injects a level of understand of XML into the doc that is probably best avoided in this case. Could make it more confusing/lead to more pedantic complaints.
AI: Scott going to come up with a suggestion offline.
We aren’t going to be able to make it completely bullet-proof.

Next call: November 6, 2019. Waiting to hear back from Colin on process.
SP22 language needs to be moved up - italicized text should have been moved up under SP21.

Pål - SDP-SP39: SP requirement SDP-MD10:Common requirements - why SP logos a MUST? Not an error on our part. There for *reasons*.

...

Versions Compared