shibboleth-dev - RE: Follow-up to design call re: path length
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: "'Howard Gilbert'" <>, <>
- Subject: RE: Follow-up to design call re: path length
- Date: Wed, 2 Mar 2005 10:22:13 -0500
- Organization: The Ohio State University
> It makes sense for a lot of people to issue a single Certificate/Key to
> the IdP and use it for both the SSO and AA functions. It is somewhat
> scholastic to require that two statements in the same Reply be signed by
> different certificates because they were issued from different roles.
We don't require that.
> Of course, one can simply put the same Certificate in two KeyInfo elements
> under the two Roles in the Metadata.
I'm afraid that's just how the schema is. I tried to get the TC to accept an
early draft that did a lot of "inheriting" of elements and then allowed
overrides, but they felt it was too complex. So KeyDescriptor is a role
item, not an entity item.
> If we agree that the algorithm runs
> Role based, I would expect that this is the way that the quickstart,
> checklist, and configuration examples would work.
Same key, you mean? Yes. Look at my example in c/configs/shibboleth.xml.in.
> The other approach works in all cases of proper use. If the algorithm were
> Entity based, then if a Role is configured with a Key and uses that Key
> its statements validate. It is just that certain "errors" don't
> get caught, as when the SSO and AA have different keys but the SSO signs
> both statements in an attribute push reply. My problem is that I don't see
> a benefit to catching these "errors".
You're slightly off. With attribute push, the SSO "role" is the one being
used, not the AA. The AA is the role used for queries only.
-- Scott
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/01/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/01/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/01/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/02/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/02/2005
- Re: Follow-up to design call re: path length, Walter Hoehn, 03/02/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/02/2005
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/02/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/01/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- RE: Follow-up to design call re: path length, Howard Gilbert, 03/01/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- <Possible follow-up(s)>
- Re: Follow-up to design call re: path length, Jim Fox, 03/01/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
- RE: Follow-up to design call re: path length, Jim Fox, 03/01/2005
- Re: Follow-up to design call re: path length, RL 'Bob' Morgan, 03/01/2005
- Re: Follow-up to design call re: path length, Jim Fox, 03/02/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/02/2005
- Re: Follow-up to design call re: path length, Tom Barton, 03/02/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/02/2005
- Re: Follow-up to design call re: path length, Walter Hoehn, 03/02/2005
- Re: Follow-up to design call re: path length, Jim Fox, 03/02/2005
- RE: Follow-up to design call re: path length, Scott Cantor, 03/01/2005
Archive powered by MHonArc 2.6.16.