[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] XPath Attribute Profile
Cameron Morris wrote on 6/1/2005, 3:43 PM: > On Wed, 2005-06-01 at 14:55 -0400, Conor P. Cahill wrote: > > > > Conor P. Cahill wrote on 6/1/2005, 2:49 PM: > > > > > Cameron Morris wrote on 6/1/2005, 2:30 PM: > > > > > > > So you are also proposing that the attributes in a query can be > xpath, > > > > and the asserted attributes follow your proposal. Correct? > > > > > > Correct. > > > So in addition to the XPath attribute profile - used only for queries - > you'd like something like an "XML document attribute profile" to define > the attribute name as a document or document namespace - used for > attribute statements in assertions. Hmm... I think the XPath attribute profile is the wrong approach and is too limiting. I think that the right way to do this would be to allow a service defined query (it just happens to be that the profile uses an xpath based select, but we shouldn't hard-code that solution). So like we have with <AttributeValue> (an xs:any) we should have an xs:any for the query operand (which will support xpath based operations on services that do xpath and whatever other services do on their services). This removes any ties between a particular service implementation and the profile. > > > PS. Note that there does not *have* to be a real query involved (e.g. > > the IdP can have some out-of-band knowledge that the SP would want > > some data returned and can return it as if the SP had queried it). > > > > Not that their can't be a query, just that there are situations > > where there is not an explicit query and the IdP may return > > such attributes in an AuthnResponse. > > In addition, the authnRequest will either reference an attribute > consuming service index or the IDP could use the default attribute > consuming service published in metadata for the SP. If xpath attributes > are not used for assertions, I still assume that XPath attributes would > apply to attribute consuming services. Not what I was thinking of. I was saying that the IdP could return *inside of the AuthnResponse Assertion* (or the dereferenced response using the artificat profile) the attributes that it wants to include with such a response. I was not trying to create an "Attribute Consuming service" endpoint in the metadata (does one exist now?) Conor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]