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] | [Elist Home]

Subject: Shib schema quibbles/questions

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

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

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

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

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

Powered by eList eXpress LLC