Shib schema quibbles/questions

[Scott Cantor <cantor.2@osu.edu>]

A few points, some repeated, based on the 16 schemas...any of us
(myself, Marlena, RL Bob) can mostly represent these issues on a con
call if there's room on the agenda, though we may differ on some
aspects.

1. Client IP address - There was some contention in Shibboleth over
whether the IP address in AuthnLocality referred to the client or to the
Authn Authority (like a KDC, for example). I'm presuming it's the
latter.

If so, where would the client address go? Advice, perhaps? As part of
subject somehow? We would use it in Shib (when possible) to reduce the
threat of a bearer authn assertion being stolen within it's
time-to-live.

2. Resource attribute missing from AttributeQuery - We need a way to
pass the target URI being accessed in the query for attributes from the
destination site to the Attribute Authority. Currently, there's an
attribute to carry this URI in an AuthzQuery, but not in the other two
types of queries. We can't see a use case for it being in an AuthnQuery,
but we definitely would like to have it in the AttributeQuery element.

3. Attribute scope - see my earlier note elaborating on this issue

4. AttributeLocality - again, see my earlier note in response to Simon
Godik's proposal to provide attribute authority location/lookup
information in authn assertions

5. Status information - We've been working with a bit more flexbility in
our internal proposals on message formats as far as communicating status
information in responses. In particular, the ability to define specific
statuses (perhaps with URIs?) as well as passing messages would seem
useful. Some of that may belong in Advice, but OTOH, shoving it all into
a non-normative spot seems iffy.

6. Time conditions - It seems a bit odd that a time condition would be
structured differently than any other condition, such as an audience
restriction. Why make it an attribute pair on the top level Conditions
element instead of a derived type of Condition? Perhaps to control the
cardinality and insure it only appears once?

--------
  Scott Cantor               So long, and thanks for all the fish.
  cantor.2@osu.edu                  -- Douglas Adams, 1952-2001
  Office of Info Tech        PGP KeyID   F22E 64BB 7D0D 0907 837E
  The Ohio State Univ        0x779BE2CE  6137 D0BE 1EFA 779B E2CE