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] 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?)


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