Re: Dutch eID Preso follow up. RE: Proposed Minutes for SSTC Call (Nov 25, 2014)

[Colin Wallis <Colin.Wallis@dia.govt.nz>]

<< 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.>>

Hi there.

I wanted to follow up on this, lest it gets forgotten in the subsequent discussions on the 'multiple value types' thread.

Dutch eID looks similar in scope and goals to NZ's RealMe, but implementation pieces (and patterns) are different from RealMe. 

As I said on the call we attempted to publish some of this thinking. Note that some of these docs are draft, aging, or both... :-)
http://kantarainitiative.org/confluence/display/eGov/Outside+Contributions?src=contextnavchildmode

Another fly-past to give you a sense of it, might be to look at this (admittedly pretty messy) preso to technical folks internally, attached (not mine! I am not the solution architect here!)

First difference: RealMe uses HTTP redirect binding for SP request , whereas Dutch eID is using Artifact Binding.  We use the Artifact binding for the response, I think, because at the time (2005/6) we felt that not enough was known about HTTP POST how to mitigate risks at the SPs, and whether our SPs would do the security job we wanted of them.. :-)  
You can see this here in the two Messaging Specifications on the link above:

Second difference: From broker to  attribute provider, RealMe uses Attribute Query Profile - looks like Dutch are using something like a websso profile?.  The consent is captured at AP than broker?
You can see Attribute Query in the spec above.

As per Michiel's comment on the call, NZ RealMe faced the same issues in SAML not having an equivalent HTTP/browser based profile for the SAMLv2.0 Attribute Query Profile.
NZ Privacy law meant that the user needed to consent to the release of attributes in the flow/in the session, which was why we wanted the request browser based. 

I don't think we published anything specific on this, but what we did in the end was use HTTP AuthnRequest to put the 'attribute query' in.
That's OK and there is metadata to support it.
But then we got into the static vs dynamic conundrum. So it works fine for a basic use case with one or two  'pre-known' attribute queries.
But when different SPs want different attributes/sets, due to the changing circumstances of what attributes they have already, the risk of the transaction etc ....  that was harder.
Memory is fading re this, but all I am trying to point out here, is that a browser based request for attribute query is a legitimate option (in support of Scott's comment on the call).
  
Happy holidays you folks in the US..which means you should not be reading this! :-)

Cheers
Colin
 

-----Original Message-----
From: security-services@lists.oasis-open.org [mailto:security-services@lists.oasis-open.org] On Behalf Of Thomas Hardjono
Sent: Wednesday, 26 November 2014 7:43 a.m.
To: Nate Klingenstein; OASIS SSTC
Cc: Thomas Hardjono
Subject: [security-services] RE: Proposed Minutes for SSTC Call (Nov 25, 2014)


Adding roll-call for 11/25/2014 meeting:

Scott Cantor    
Thomas Hardjono
Mohammad Jafari  
Nathan Klingenstein     
Hal Lockhart    
Scott Robertson
Colin Wallis
Remco Schaar
Michiel Dollenkamp

Quorum was achieved.

________________________________________
From: security-services@lists.oasis-open.org [security-services@lists.oasis-open.org] on behalf of Nate Klingenstein [ndk@internet2.edu]
Sent: Tuesday, November 25, 2014 1:04 PM
To: OASIS SSTC
Subject: [security-services] Proposed Minutes for SSTC Call (Nov 25, 2014)

> 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/msg0000
> 8.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/msg0000
> 4.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/msg0000
> 9.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.
---------------------------------------------------------------------
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

Attachment: RealMe Technical Overview 2013 v1 1.pdf
Description: RealMe Technical Overview 2013 v1 1.pdf