Re: [security-services] Proposed Minutes for SSTC Telecon (March 17th, 2

Subject: Re: [security-services] Proposed Minutes for SSTC Telecon (March 17th, 2015)

Met vriendelijke groet,

drs. Martijn Kaag

tel +31 (0) 88 01 20 222 | gsm +31 (0) 6 42 94 00 93 | skype martijn.kaag-connectis

On Tue, Mar 17, 2015 at 5:40 PM, Nate Klingenstein <ndk@internet2.edu> wrote:

> 1. Roll Call & Agenda Review.

Quorum was achieved.

> 2. Need a volunteer to take minutes.

Nate volunteered to take the minutes.

> 3. Approval of minutes from previous meeting(s):
>
> - Minutes from 17 February 2015 meeting:
>
> https://lists.oasis-open.org/archives/security-services/201502/msg00003.html

Scott moved to accept the minutes. Hal seconded. There were no objections and the minutes were adopted.

> - Martijn had indicated that he is interested to work on the 2.1 project.

Martijn was unable to join us on this call. He had indicated interest in doing this work, as noted in the agenda, but we don't know whether the full scope of the work was apparent at the time of that _expression_. We would be interested in hearing more about the interest and resources that could be available to perform this work.

> (e) XSPA updates (Mohammad Jafari)
> - Any updates.

There is no specific work on the SAML integration for XSPA because there are other more pressing issues for the working group right now, but Mohammad will inform us when they are ready to pivot, so we will leave this as an agenda item.

> (f) Clarifications for algorithm support for metadata extension (Scott)
> - Was there any AIs from last SSTC meeting?

There's a small action item that Scott will need to do, but we don't need to worry about it as the SSTC, so this will be removed from the agenda for future calls.

> 5. Assorted mail items:

Colin Wallis was unable to join the call due to time zone differentials, but he sent out a message to the SSTC list that we reviewed thoroughly on the call.

https://lists.oasis-open.org/archives/security-services/201503/msg00002.html

Having the relying party also request consent of the user seemed counter to most of our deployment experience, where the user is typically only prompted for consent by the IdP. There's a consent attribute in SAML [assertions, presumed by minute taker with little time today, dunno exactly where] that is a little "historical", but we are not familiar with how it is used in production by various deployments. There seems to be a parallel attribute in AuthnRequests.

The request seems to pivot around the ability to dynamically request attributes to be returned. Today, SAML is engineered to handle a free-standing attribute query with dynamic attribute request or list information in metadata designed around statically configured use cases where you know in advance what attributes are needed.

The crux of the issue, from the SSTC's perspective, is that there are actually two different kinds of attribute release mandates in the SAML specifications: advisory, like metadata, and normative, like attribute queries. When you specify an attribute set in a query message, there are normative requirements that prevent the IdP from returning things that were not requested. In the metadata case, it's just informational: trying to tell IdP's what release is necessary for the application to work, but without any normative rules around what is permissible. In the attribute query case, the IdP is not required to return every attribute requested, but it acts as a filter; it's the maximum set that may be returned. They appear to want to designate a maximum set of attributes to be sent using metadata.

We presume that the second point in the message was just about giving the user a point of consent in deciding whether attributes should be released, but it could be inline or out of band. This may have the potential to be realized through use of the old consent attributes defined in the original SAML 2.0 specifications, without actually defining an extension if the old consent attributes in the old specification work.

Someone will really need to look closely at the OpenID Connect specification to deeply understand what is being referenced before we can really understand how to represent the same functionality in SAML most effectively. We had nobody with the time available on the call to volunteer to do the investigation.

We're not sure how scope is applicable to SAML; perhaps it's closer to an audience restriction.

The other consideration is the delta between getting the specification written, and getting real world support in both implementations and deployments. If there were a deployer who was very serious about the feature giving funding saying it was a top priority, then that would obviously influence how much time would be invested. Our concern is that the newer specifications have not seen high uptake by the many and varied implementations of SAML, so it's unclear how much weight a specification alone would carry.

We would like to learn more from Colin about the goals here, and the extent to which they are serious about the mandate. As a government, they may have more tools to incentivize vendors to implement features that they care most about.

We assigned no action items at this point since we're still in the information gathering phase and we're looking to Colin to have a chance to interpret and respond based on what's captured in these minutes.

> 7. Next SSTC Call:
> - Tuesday 14 April 2015.

We look forward to talking to you all then. Take care.
---------------------------------------------------------------------
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

security-services message