Shibboleth Developers

[Scott Cantor <>]

> > -- RP, point 4, 2nd sentence --  If the providerId value matches a 
> > DestinationSite entry in the metadata, and there is a RelyingParty 
> > element that has the same providerId as the URI of the the federation, 
> > that RelyingParty is used. If not, the default relying party handles 
> > the request. (make sure this sentence  is correct....)
> 
> Almost.  The Relying Party's "Name" is what is matched against, not its 
> providerId.

Put another way, in the origin config, the providerId attributes dictate you
who claim to be when you send messages to targets. The RelyingParty "Name"
is matched against the *target*'s providerId or site group value.

So a RelyingParty providerId tells the origin to claim to be that particular
entity when sending messages to matching targets.

> > 24) 5.b.i, sentence 1, 2 - change to?  When a request arrives from a 
> > particular relying party, an effective ARP is constructed as follows:
> 
> I wouldn't say from a relying party, but from an "application".  NOTE: 
> The relying party thing is only a mechanism to select configuration 
> data.  It is not an identifier for the requester.

I'd rather not have "application" show up as something origins talk to, even
just saying "target" or "requester" would be better. The target should be a
black box to the origin and vice versa.

-- Scott