[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: Metadata support: Extensions handling
From:       Brent Putman <putmanb () georgetown ! edu>
Date:       2013-08-15 21:50:29
Message-ID: 520D4D25.4020908 () georgetown ! edu
[Download RAW message or body]


On 8/15/13 5:22 PM, Ian Young wrote:
> > Well, actually, in that specific example, IIRC each KeyAuthority gets
> > turned into a distinct instance of PKIXValidationInfo. 
> That's a design choice too, of course.  Personally, having a single "trust context" \
> that knew about all of the trust material that was in scope would make more sense \
> to me, but if you've already made the decision that the person processing the node \
> needs to do the enumeration then that's moot.

Yes, but the design choice wasn't in OpenSAML, it was in KeyAuthority.
What OpenSAML does it actually determined/dictated by a specific thing
related to the KeyAuthority schema. Each KeyAuthority can specify a
distinct verifyDepth property.  Since the PKIX eval operation takes the
verify depth as a param, you can't really lump all the potentially
multiple KeyAuthoritys into one big set, since they might have different
verifyDepths.  And I think that the schema was designed that way because
conceptually, the KeyAuthority is intended to define something like a
distinct "trust context", with one or more trust anchors and supporting
material, and the assumption is you can have more than one trust
context.  At least IIRC from reading the old code, that's how it was
treated in v1 and we preserved those semantics in v2.
--
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]