Proposed Minutes for SSTC Call (Nov 25, 2014)

[Nate Klingenstein <ndk@internet2.edu>]

> 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 30 September 2014:
> https://lists.oasis-open.org/archives/security-services/201409/msg00006.html
>   - Note: slight correction to the Minutes which states that previous meeting was 19th September (whereas it should say 16th September).
>   - Minutes from 28 October 2014:
> https://lists.oasis-open.org/archives/security-services/201410/msg00008.html

Scott moved to approve both sets of minutes and Hal seconded.  There were no objections and the minutes were adopted.

>  (c) Presentation on Dutch eID (30 mins)
>      - By Michiel Dollenkamp
>      - Slides:
> https://lists.oasis-open.org/archives/security-services/201411/msg00004.html

Michiel went through these slides for the SSTC.

Sector ID providers would be, for example, an entity capable of authoritatively providing specific types of information, such as a health care number or a bank account number.  The same authentication provider would be used, but multiple attribute sources would be collated through a broker when the trust needs and use case permit.

The broker can be thought of an agent of the service provider in many cases.  Aggregation of multiple assertions by a single broker makes the resulting data easier for a service downstream of the broker to use the information as it is flattened into a single assertion with unified data, but some trust information may be lost in the process.

Encryption can reduce the amount of information that the broker can see, but trust in the broker is still required to appropriately associate attributes with users. They’ve chosen to use EncryptedID and EncryptedAttribute to enable brokers to do this.

Custom URI’s for AuthnContext are used to signal the level of authentication in any given transaction.  Scott observed that the predefined ones are not widely used anyway; this is use of the mechanism as it was expected to be used.

Attribute queries over asynchronous bindings become tricky when you try to inject user consent into the flow in a way that is sensical to users.

Scott thinks there may be over-signature; it seems like overkill to him given the cost of doing so.  The general preference nowadays is to sign the outermost layer and nothing else.  This is passing along assertions in ways that were not anticipated by SSO, so you need to think more deeply about integrity possession.  It’s also fairly easy to misuse assertions in ways that would break security assumptions that are made by all identity protocols using bearer tokens.

If all the information that is received from IdP’s is encrypted, how does the broker know how to associate that information?  How does the broker know what to put in the Subject if all the information is encrypted?

They have use cases that require delegation of action.  The user is authenticated to the broker, and then the user is sent to the authentication information provider to choose an authentication to act as.  An example was presented with four assertions, two declaring an attribute each, one for authorization, and one for identity.  Assertions could be linked using the same transient identifier in multiple assertions.

The subject of the summary assertion is intended to be encrypted.  Subjects of upstream assertions are used for association of assertions and shouldn’t be encrypted.

Scott observed there is no way to have multiple EncryptedID’s as Subjects in a single assertion, but it’s easy to place them in an attribute statement.  Meta-information could even be included like the intended recipient of an identifier which would allow multiple encrypted ID’s for different providers, for example.  He emphasized that the broker can pull data out of the assertion and use it in various ways when transacting with other providers.

Some of the selection of EncryptedID or attributes depends on the capability of the service provider that lies downstream of the broker.  Scott thinks that a good SAML implementation shouldn’t completely disambiguate between attributes and the Subject and should permit mixing and matching, but Michiel observed that there are a number of implementations that don’t have totally elegant implementations.  Scott countered that violating the specification for a broken implementation isn’t a solution and he doesn’t think use of attributes is such a big deal.  He also thinks SubjectConfirmation will not be honored by any implementation that can’t understand detailed or multiple attributes.

Michiel observed that there was a deliberate decision made to make the broker as flexible as possible in working with providers, but Scott doesn’t think SubjectConfirmation is as widely supported as attributes.  If you don’t follow the standard, then there’s little point in just following the syntax.  It’s not just a message format that allows you to create bags of data.  If you want software off the shelf that works with a standard, they’ll need to follow the standard.  Otherwise, if it’s all within one closed network, there’s less value in recycling SAML.

Scott also noted that the front channel attribute query concept has arisen multiple times.  He understands the consent implications and so forth.  His confusion is that, if you just look at the Attribute Query Profile’s protocol, it doesn’thave the same security processing rules that the Web SSO profile does.  Interoperability will be a challenge here.  He’s concerned about attributes being passed back without any of the security protections, such as audience restrictions or bearer conditions.

Michiel feels that message integrity is covered by mechanisms included, but Scott thinks that passing a message over the front channel using the artifact binding, which means the security semantics are driven by the browser, not the rest of the flows.  The artifact mechanism itself is a bearer assertion, but the protections that the Web SSO profile has are not included, and Scott doesn’t think it creates a lot of value beyond just using a typical authentication request.

If you want to specify requested attributes in an authentication request, he thinks a specification to do just that would make sense.  Attribute queries were really designed for the back channel.  A front channel flow to an attribute provider makes it an IdP because it needs user authentication implicitly and it makes sense to just use the Web SSO Profile to do that.

In New Zealand, AuthnContext was used to achieve use cases similar to the ones presented by the Netherlands.  The Kantara Initiative has published a specification.

Numerous questions posed both by the presenters and the SSTC remain to be answered.  The SSTC is interested in actively pursuing further conversation around profiling this use case because it is arising repeatedly and we’d like to encourage a consistent approach.

> https://lists.oasis-open.org/archives/security-services/201410/msg00009.html

Hal added that XACML treats multiple different attributes elements with the same name but different values as a single multivalued attribute.

>   - Tuesday 23 December 2014.

We’d like meet on the 23rd of December even if it’s brief with light attendance to ensure we keep the cadence.