[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]