Skip to Content.
Sympa Menu

shibboleth-dev - RE: Trust metadata for discussion

Subject: Shibboleth Developers

List archive

RE: Trust metadata for discussion


Chronological Thread 
  • From: "RL 'Bob' Morgan" <>
  • To: Scott Cantor <>
  • Cc: "'Shibboleth Design Team'" <>
  • Subject: RE: Trust metadata for discussion
  • Date: Fri, 16 May 2003 00:44:01 -0700 (PDT)


On Wed, 14 May 2003, Scott Cantor wrote:

> That's roughly where we are, once the single file is fixed. But it still
> requires answering the question of what happens when osu.edu is listed
> in both files.
>
> My inclination is to acknowledge that URIs are better, and have
> mace:urn:InCommon:osu.edu and mace:urn:osu.edu:ClubBuckeye
>
> This seems to me to "just work" in the 1.0 code. The 0.8 code relies on
> site names for auto-scoping of attributes, but that is finally gone in
> 1.0.

OK, yes, I like the idea that an "origin site" is not monolithic as we've
had it, but "an organization and a purpose". My campus can and will have
multiple "sites", each essentially UW, but each with a different face to
the world, hence different crypto support, different policy values,
different URL entry points, etc; hence each given its own name. This begs
the question of how small of a difference obliges me to create a new site,
but this is kinda like the eternal question of why to make a new
federation; so it will work out in practice, probably.

Seems to me this might even help with transitions we're facing. My
current "UW site" isn't really "UW", it's "the UW site participating in
the InCommon pilot". The production site we put up to participate in real
InCommon should be differently identified, so a target could potentially
work with both during transition or for testing.

I agree with the motivation to have naming and metadata support federation
but not embed federation-specific mechanics into them. Thus a federation
might offer or impose structure on site names, but it might not; and a
site name can exist independently of any federation. Using the federation
ID, supplied via Audience, to find basic site info (ie, the modified API
suggestion) does seem like injecting feds too much into the mechanics.
That said, it does seem to me that Audience has a potential role to play
in policy selection by the target, so it should be available for this
purpose in the APIs, even if we don't quite know what we'd do with it yet.

I'm inclined to say that we should proceed with making site names into
URIs ASAP, so as to start moving more clearly in this direction.

- RL "Bob"


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at

http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--




Archive powered by MHonArc 2.6.16.

Top of Page