Shibboleth Developers

[Scott Cantor <>]

> Let me sketch out the approach below.  Probably you've 
> already got the approach you've proposed implemented, but let 
> me try to make this case anyway.

I've only completed the basic plugin design, but not the details or the 
validation code.

I think what you're proposing here is basically just the converse of what's 
there now, and what the application (Shib in this case)
wants to know. I as a relying party don't want to ask the question "For this 
PKI object, what can it be used to verify?" but rather
"For this system entity/purpose, what PKI object(s) do I verify with?".

So either way, I'm not changing the important API, because it would be bad if 
the application had to go walking through the CA
policy from the other end. It's like the XACML problem...there we wanted to 
know what attributes we could release, not whether a
specific attribute was releasable.

The one issue I see that creates a bit of a slippery slope design-wise is the 
language used to describe what it is that an
"Authority" is to be used for. That is, it's not likely that a "name" or URI 
is sufficient in the abstract, especially if it's just
a DNS name. Is it a HS? An AA or SHAR?

> which of course has more or less the semantics of a cert 
> itself (excepting dates and such), which is part of the win 
> I'm looking for here.  If the underlying trust-store of the 
> target system ever has a way of saying "trust this key for 
> this name", then the above construct can go away, without any 
> side-effects.

Right, I guess the slippery slope is that certs are really complex for 
reasons that we all understand. They theoretically are
supposed to support statements about what it is that a key/name binding is 
valid for (key usage). I don't want to try and design all
that. Maybe SAML will someday, by defining new condition and statement types.

If I think I can get away with just using a name or a regex and not some kind 
of "purpose" vocabulary, then it might be doable.

> Right, the proposed scheme requires there to be some way for 
> the things-that-are-being-verified to be referred to.  Each 
> site has a name/URI, and so is easily referred to.  HSs and 
> AAs have DNS names, ditto.  Site-groups and <Sites> 
> aggregations don't have names/URIs at this point, perhaps 
> they should.  I don't know enough about XLink and such kind 
> of references to know whether they'd be useful here.

Well, the SiteGroup does have a Name attribute. They weren't really fleshed 
out, but that was in there. Sites is really kind of a
container element, kind of like soap:Envelope. XML requires some kind of 
document root, and most document-style schemas define
something fairly generic for that so that apps can dispatch on the root.

Well, I can't promise I'll have something perfect by Monday, but I'll try to 
see what I can come up with.

-- Scott

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

    http://archives.internet2.edu/

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