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] Re: Dutch eID Preso follow up. RE: Proposed Minutes for SSTC Call (Nov 25, 2014)


So I am overdue a response on this.
After the SSTC call/Dutch eID preso, I reached out to Scott for more clarification, and to Thomas to help me reach out to Michiel.
My sense is that NL and NZ have the same issues, have tackled them differently (NL with Artifact, NZ with AuthnRequest, but neither are optimal vs WebSSO.

But those motivated would have to document how to support attribute elements in the request, right?... 
..and in so doing, preclude the need for a front channel version of the AQ profile..
Would NL be motivated enough to work on it? I get  a sense from our architecture team that ... 'if you will, we will'.. :-)

NZ can probably help NL regarding the user consent to release attributes. .. see this Kantara eGov page for a starter on NZ's approach but I may have to dig out more details for you
http://kantarainitiative.org/confluence/display/eGov/Outside+Contributions?src=contextnavchildmode
  
Cheers
Colin

Colin Wallis
Standards Architect
System Transformation
Department of Internal Affairs
New Zealand Government
www.ict.govt.nz
DDI: +64 4 816 4077
Cell: +27 244 7135
out of office email: colin_wallis@hotmail.com
http://www.linkedin.com/pub/colin-wallis/4/127/792


-----Original Message-----
From: Cantor, Scott [mailto:cantor.2@osu.edu] 
Sent: Wednesday, 10 December 2014 12:49 p.m.
To: Martijn Kaag
Cc: Colin Wallis; OASIS SSTC; Jeroen Ruigrok van der Werven
Subject: Re: [security-services] Re: Dutch eID Preso follow up. RE: Proposed Minutes for SSTC Call (Nov 25, 2014)

On 12/9/14, 10:07 PM, "Martijn Kaag" <martijn.kaag@connectis.nl> wrote:


>
>I agree, but there are several challenges:
>
>* They need to communicate the requested attributes at runtime. For 
>several reasons, AttributeConsumingServiceIndex is insufficient (there 
>may be more than
>65535 different combinations of requested attributes). 

That only holds if you signal some attributes as required vs. just handling the error at the SP, but that's fine. It's a trivial extension. 
And yet in ten years nobody who actually has the problem is willing to work on specifying it? That's hard to take seriously, for me.

>* They need to communicate about the (authenticated) subject with more 
>than one attribute.

And so there are multiple Attributes in any statement. I don't see the problem there.

> 
>* They need specific user consent for every released attributes.

That's out of scope of SAML, but there are plenty of implementations that do that. Even Shibboleth's about to.

>Another option would bean authnrequest with a set of requested 
>attributes in the extension.

The other option is to invent a query profile that adds back in all of the security content, subject confirmation rules, etc. from the SSO profile. I think that's a lot more work.

-- Scott



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