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: Re: [security-services] Minutes from SSTC Call (Tuesday 22 November 2016) ---- RE: Proposed Agenda for SSTC Telecon (Tuesday 22 November 2016)


Thanks all for the comments received yesterday!

I confirm that I understood your feedback and will try to add the explanatory processing rules that should clarify special cases where both the ACS way and the proposed extensions are used together. 
I will upload the new version once it is ready and fill in the form to use the working draft template.

Have a nice day,
Madalina

On Wed, Nov 23, 2016 at 9:38 AM, Rainer Hoerbe <rainer@hoerbe.at> wrote:
would like to add some text to 4c).
> Am 22.11.2016 um 19:48 schrieb Thomas Hardjono <hardjono@mit.edu>:
>
>
> 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).

Scott proposed wording to clarify that requested attributes defined for an ACS are the preferred option if the set of attributes does not change, as it is a static element that does not need to be processes for each request.

- Rainer

>
> 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).
>
> --------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Connectis accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


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