OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes from SSTC Call (Tuesday 22 November 2016) ---- RE: Proposed Agenda for SSTC Telecon (Tuesday 22 November 2016)


Minutes from SSTC Telecon (Tuesday 22 November 2016): 

1. Roll Call:

Madalina, Hal, Thomas, Scott, Rainer, Mohammad.

Quorum achieved.


2. Need a volunteer to take minutes.

Thomas taking minutes.


3. Approval of minutes from previous meeting(s):

- August 30th, 2016 meeting:
https://lists.oasis-open.org/archives/security-services/201608/msg00003.html

Motion: Rainer.
Second: Scott.
No objection. Motion passes, minutes accepted.



4. AIs & progress update on current work-items:

(a) Current electronic ballots: None.
(b) Status/notes regarding past ballots: None.

(c) Requesting-attributes extension (Madalina)

https://lists.oasis-open.org/archives/security-services/201611/msg00010.html


Madalina: This document was submitted/discussed in the SSTC starting last year, and now want to continue.  The goal is to provide a wrapper element to support more flexibility in federation-related scenarios.

The context is the eIDAS project and regulations in Europe.  eIDAS follows from STORK in Europe, and different countries in Europe are in different stages of deployment (some on eIDAS, some on STORK, some "rolling their own"). So it is desirable to standardize how attributes are requested.

Scott states that the draft looks fine. Just needs to use the OASIS template doc.

Rainer: asks about how to ensure there is no confusion on the part of the IdP regarding which mechanism to use (this proposal, via metadata, but not both).

Scott: Add some text in the document that makes the semantics and usage very clear to the IdPs (e.g. if extension is present then must use it).

Thomas asks for a motion to move it to become TC work-item.

Scott: motion to adopt this document as TC Working Draft (TC work item). Rainer: seconds.  No objection. Motion passes.

Action Items:  
- Thomas to ask TC-Admin for new template for this doc.
- Madalina to make corrections per input from this meeting.



(d) Protocol extension for role change (Rainer).

https://lists.oasis-open.org/archives/security-services/201611/msg00000.html

The use-case pertains to changing roles within a session. Whenever a role-change is required, the user should be able to select the new role without logging off. Then the role-change needs to be propagated to all active SP sessions to avoid confusing the user.

Scott: SLO currently is not widely adopted, and may not help Rainer's use-case. Perhaps better to look into solving this in the application. Also need to get around the 3rd party cookies problem.

Rainer: there are some limited implementations of back-channel logout. But for front-channel logout, the issues also include the UX to the user.  Moving it up to the application may require lots of application to be modified.

Scott: The notion of roles/context is not sufficiently captured in the current specs. So, to incorporate this feature may mean lots more spec work.

Rainer: will go back to his developers/implementer to communicate this, and see if there are other approaches.


(e) Integration of token binding into SAML (Scott)

https://lists.oasis-open.org/archives/security-services/201608/msg00005.html

The token binding proposal (in the IETF) is a TLS extension that allows supporting HTTP clients to prove possession of a private key, so that it can be used by higher level applications.

Scott: if SAML wants to support this binding, then we could look at SubjectConfirmation.

Scott reports that in his conversations with folks in higher-education communities, there interest (concern) that Google is deploying their QUIC (Quick UDP Internet Connections) protocol at a broad scale - replacing TLS.

For SAML TC, if there is interest in binding to this new protocol, there will need to be new profile(s) written.


6. Next meetings:

(i) Tue, 14 Feb 2017.

(ii) Tue, 09 May 2017.

(Note that we are meeting roughly every 3 months or 12 weeks).

--------------------------------
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]