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

On Tue, Apr 22, 2008 at 11:06 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> > 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?

You mean lines 165--172?  Those lines are too far away from the
elements in question, so I'd still say something's missing.  Does it
make sense to include a xref where those lines apply?

>  > 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.

I can buy that argument, and I could probably even figure out how to
support this in my implementation, but that isn't what I get from
reading the spec, hence this proposed errata.

I've read the proposed text in the errata document, but I don't think
it has the same flavor as the above.  Can you take another crack at


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