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] PE67: Absence of elements in metadata


> First of all, I totally agree that omitting an element (such as
> <md:NameIDFormat>) altogether does *not* imply that none are
> supported.  This makes perfect sense.

Meaning that the original note in the spec is probably sufficient on that
score?

> An IdP lists attributes A1, A2, and A3 in metadata.  An SP requires A4
> to provide access to resource R.  Should the SP issue an expensive
> query to the IdP in hopes of obtaining A4 (even though the IdP does
> not advertise A4's availability) or should the SP simply deny access
> to any request for R that requires a query to this particular IdP?

That depends on whether the SP has OOB reasons for believing the metadata
isn't exhaustive.

It may believe the metadata is simply a subset of the IdP's capabilities but
has a private set of listed attributes it knows are supported. Etc. It's out
of scope.

Right now it's an implementation matter as to whether an SP would use
metadata or not for a particular feature, and how authoritative to treat it.
I realize that's not perfect, but the only other option is to force people
to support metadata, and we don't do that at the moment. Since we don't, we
can't depend on it being the only possible input to an implementation, and
the metadata spec reflects that uncertainty, I think.

-- Scott




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