Shibboleth Developers

IMPORTANT E-DIAL PHONE NUMBER HAS CHANGED AS OF Jan 1!

1-866-411-0013 (toll free US/Canada only)
or 1 -800-392-6130 (alternate toll free US/Canada only)

for callers outside the USA/Canada dial 1-734-615-7474 (not free)

Pin # (remains the same): 0142203

Agenda:

1) Startup
      - Roll call, agenda bash
      - Intellectual Property Rights Awareness: Internet2 
Intellectual Property Framework
                (http://members.internet2.edu/intellectualproperty.html)

2) Short items / outstanding Issues?
        - shib wiki rollout -- comments, reactions?
        - java target, status of draft cookbook.
	- updated versions of Shib spec's now available -- comment 
now, before the window closes...

At 6:16 PM -0500 2/11/05, Scott Cantor wrote:
> From: "Scott Cantor" 
> <>
> To: 
> <>
> Subject: Updated specs
> Date: Fri, 11 Feb 2005 18:16:47 -0500
>
> I've uploaded new drafts of the protocol and conformance documents to the
> web site, and there's a new draft of the metadata profile on the SSTC site
> as well.

	- shib IdP install  checklist -- new version likely being 
published this week

http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Version-3/Checklist/identity-provider-checklist-draft3.html

        - other items?

3) Discussion -- potential SunGuard code contribution. Vishal Goenka 
from SunGuard will be  joining the call.

4) Discussion -- text from latest version of LionShare profile of 
SAML pasted in at bottom; any comment?

4) Discussion -- framework for error handling, error reflection in 
the SP implementation.

	-- following last week's discussion, what steps do we want to 
take? Here's my notes from that call:

> -- different apps have different requirements (eg intranet vs 
> library vs external);
> -- obviously good idea to catalog all the errors, and structure how 
> they are reported to various endpoints
> -- Peter M -- asking for software to distinguish IdP from SP errors; 
> Scott -- this is impossible....
> -- Scott -- the service needs to be robust + intelligent; provide 
> feedback about what was required  and what was provided; let user 
> decide where to report it......
> -- Scott -- our experience with elsevier (their pages should tell 
> user what to do, rather than shib pages trying to provide 
> feedback....)
> -- ? does user  get sent to library help desk, IT help desk, or SP 
> help desk....
> -- develop best practices guide for SPs, re the various errors.....
> -- 1.3, by default, will  suppress attribute related errors..... the 
> application will need to respond appropriately.


---- LS profile of SAML summary text ----------------

<P><b>Obtaining Attributes</b>

<li>Request Attributes

	<p>The LS client opens an SSL connection with the local 
Shibboleth Attribute Authority; it uses its client cert to create the 
SSL tunnel. (The cert for the local SASL-CA is included in the 
ca-bundle file, or whatever other file shib v13 will use for 
validation.)

	<p>It MUST send a <samlp:AttributeQuery> (inside a 
<samlp:Request> message).

	<p>The message MUST contain HTTP headers with a 
version/useragent indicator  (This implies NO ARP processing....)

--- can someone suggest exact syntax to use for these?

	<P>The <samlp:AttributeQuery> MUST contain a Subject element, 
which MUST contain a SubjectConfirmation element, asking for 
Holder-of-Key confirmation method.

	<p>The <samlp:AttributeQuery> MAY contain a 
<saml:AttributeDesignator> to specify which attributes are desired.

<li>Return Attributes

	<p>The AA validates the certificate used to create the SSL 
tunnel. The AA MUST validate that the handle in the cert matches the 
handle in the Subject element. Consequently, there MUST be NO ARP 
processing applied to the set of requested attributes.

NOTE -- this validation process will be done by a new trust plugin, 
as mentioned in previous notes. That plugin will  be configured to 
use JUST the cert from the local SASL-CA.....

	<p>The AA uses the handle (obtained from the client 
certificate) to identify the user and retrieve attribute values from 
the user's directory object. It uses the supplied 
<saml:AttributeDesignator> to determine which attributes are desired.

	<p>The AA creates, signs, and returns a <samlp:Response> 
message, which MUST contain a <saml:Subject> element containing a 
<SubjectConfirmation> element with a <ConfirmationMethod> of 
Holder-of-Key. The <SubjectConfirmationData> element MUST contain the 
certificate

-- actually, should it contain the full cert, or just the key from the cert?

used to create the SSL tunnel. Additionally, the Response MAY contain 
one or more <saml:AttributeAssertions> containing attributes that 
apply to the principal.