Re: [security-services] Proposed Enhancement for Dynamic Attribute Queries

[John Bradley <ve7jtb@ve7jtb.com>]

As part of Connect we have done a structured attribute request and response.

It will be interesting to see if in real life it gets used for more than could be accomplished by something like AttributeConsumingServiceIndex (scope in OAuth).

The privacy people in the UK and US are driving some of this.   In general I support solutions that support privacy and control if they get used.   The getting used is most often the rub and outside the control of the SSTC.

John B.
On 2012-03-28, at 3:58 AM, Cantor, Scott wrote:

> On 3/27/12 7:23 PM, "David Chadwick" <d.w.chadwick@kent.ac.uk> wrote:
>> 
>> So why is the feature in the attribute request message? And has been
>> there from v1 of SAML?
> 
> Because copying/emulating basic features of LDAP was one of the original
> use cases, and because metadata didn't exist in V1 of SAML (nor, I would
> note, did AuthnRequests at all).
> 
>> If you have a model of an all attribute providing IDP, and an SP that
>> offers multiple services with different authz requirements, then you
>> need a feature such as this
> 
> I think it's pretty clear that most of us think that metadata is
> sufficient for *most* such cases, and it handles multiple services just
> fine, in multiple ways. Where it's not sufficient is mostly with respect
> to how it identifies attributes, which I haven't evaluated in the context
> of your proposal yet.
> 
> There isn't any experience at this point in identifying how far down the
> complexity scale one has to go to get to the right attribute enumeration
> mechanism. XACML is, frankly, too complex IMHO. The metadata schema is
> clearly not complex enough.
> 
> What I do think is that whatever extension were to be adoped for an
> AuthnRequest should also be defined as usable in metadata as a replacement
> for AttributeConsumingService.
> 
> -- Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-services-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: security-services-help@lists.oasis-open.org
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature