Shibboleth Developers

["Scott Cantor" <>]

This looks like a good start to me. Some comments and suggestions are
inline below....

-- Scott

> 1.2    Club Shib
>
> Club Shib will provide the following functions to its members:
> 
>    c.  Targets will be required to not cache attributes excessively...
>    d.  eduPerson 1.5 and eduOrg 1.0 must be implemented for
attribute...

Can these be omitted from this section, since they're repeated in the
section on obligations of origins/targets and aren't really a "service"
or "function" of the club?
 
>    e.  A WAYF will be provided by Club Shib's Wayfarer service.  This
> utilizes a membership list which will include addresses and private
keys
> of SHIRE's and HS's within the club and will be distributed as a flat
> file.

We're still evolving what the files will contain, but Bob's recent
proposal on attribute acceptance issues is a good second cut at what the
really important signed document will contain. To support the "SHIRE as
WAYF" situation that we're in now, we can add to that or document a
second file for the WAYF information, which is really just a set of
aliases to assist in searching.

We should decide whether my suggestion to allow a university to provide
only a HS name without a certificate and rely on checking the signing CA
at runtime is acceptable policy or if that's insufficient to drive the
rest of the trust. The advantage obviously is less (re)distribution of
keys.

> 2.     Club Shib Application Process
> 
> 2.1    Initial Application
> 
> 2.1.1  All applicant organizations will agree to:
> 
>     a.  Use an implementation of Shibboleth that:
>             i. Complies with everything in the Shibboleth Architecture
v4

Can we say Shibboleth Architecture 1.0 here? We should be at 1.0 soon, I
hope.

>             iii. Uses SSL for all interactions between Shib
components,
>                  including the AA, HS, SHIRE, SHAR, and the user.

We might want to break this into two requirements. The first one
specifies use of SSL between the browser and the HS and SHIRE. Do we
need to mandate the strength of encryption here?

The second piece is the SHAR/AA. I'm comfortable with requiring SSL with
client cert authentication in the Club (as opposed to in the arch doc).
We can reference the URI for the SAML SOAP binding once it's chosen.

>     b.  Provide certificates that comply with Club Shib PKI
certificate
>         profiles, and trust the Club Shib specified roots.

A profile is a good idea, with the caveat that we may be dealing with
commercially-issued certificates in some cases. What can we impose on
those?

> 2.1.2  An applicant origin will agree to:
>     f.  Implement eduPerson 1.5 and eduOrg 1.0(including campus
account
>         management procedures)

In what sense is this required apart from the attributes that we plan to
support?

>     g.  (place holder) Ensure that the RHS of your EPPN attributes IS
the
> same as the value your AA is placing in the SecurityDomain element
>     h.  Agree that you will only issue Assertions about your 
> Security Domain

Guess we can begin to flesh this out in terms of specifying that the
scope of any attributes be from the set that you apply for control over
when you submit your application.

>     i.  Provide the DNS and associated certificate of the origin's HS

See earlier comment regarding certificate.

> 2.1.3  An applicant target will agree to:
> 
>     b.  Provide the DNS and associated certificate of the target's
SHIRE

Should be unnecessary initially, although if we move to allowing the
SAML artifact profile or use signed requests to HS to fetch attributes
as an optimization, we might need it. Any server in the world could
currently request a handle, and technically it's even up to the AA
whether to release attributes to non-club members, I guess.

> 3.     Club Shib Functions and Obligations
> 
> 3.1    Club Shib Obligations
> 
> 3.1.1  Organizations Already in Club Shib:
> 
>     c.  Must support and implement XML signatures, but use is optional

Don't think we need this initially. I'm not sure we want to mandate
support for it on attributes, since our initial implementation won't.
;-)

>     d.  Should perform all redirections through HTTP, not HTML

Just omit this. The SAML browser profile (and thus the arch doc) is
explicit about how redirection works.

>     e.  Must reference this document in the audience field of 
> all assertions

Change to something like "the policy URI xxxxx" instead of "this
document".

>     f.  Should use the MACE URN namespace whenever possible

I'd omit this also, unless it's clearer what this means. Many of the
URIs will be chosen by us. Maybe we want to say that MACE URNs should be
used for custom attributes, but let's clear that up on our end first.

>     g.  Should use eduPerson 1.5 and eduOrg 1.0 whenever possible

Not sure what the intent is there.

> 3.1.2  Origins Already in Club Shib:
> 
>     c.  Should set an AA attribute lookup timeout of 30 seconds

How about a more general statement about desired attribute request
performance? How common is this? Does MACE-Dir specify expected
performance on directory lookups in general?

> 4.     Trust in Club Shib
> 
>     Trust in Club Shib is provided using a signed package of 
> data that associates names, organizations, and public keys in 
> a searchable way.  These data are signed and distributed by 
> Club Shib in a format that is easily useful for AA's and 
> SHAR's.

It's SHIRE and SHAR that use it, not the origin pieces.

> The SHIRE, SHAR and AA should be configured with a 
> set of trusted roots to use in validating the certificates in 
> the local database or passed in exchange by SSL or XML 
> signature envelopes.

Change to: The SHIRE, SHAR, and AA must be configured with a set of
trusted CA certificates to use in validating the certificates exchanged
in SSL or signed XML messages.

> Trust of the target side comes 
> primarily from the knowledge of the SHIRE and the trust of 
> the SHIRE to not accumulate or pass on attributes 
> inappropriately and to not allow inappropriate SHAR's to use 
> it for attribute requests.

It's pretty much entirely the SHAR that is being trusted. The SHIRE is
ignored and basically unknown. The SHAR authenticates by providing a
certificate signed by a trusted authority that indicates its name and
proving it knows the private key (via SSL in our current case).

> DNS will be leveraged to look up 
> local certificates using the CERT resource record and to 
> verify the subject names of SSL server or generic 
> certificates.

We haven't mentioned resource records. Lord knows we're probably out of
luck, I think our DNS is ancient...

> AA's will use the distributed list to 
> preconfigure mappings between SHAR names and target URL trees 
> to allow users a simple means to evaluate and change ARP's.

We definitely need to document this. This should probably be a target
requirement to join the club (providing the list).
  
> SHAR's will, by default, accept attributes such that 
> attributes must be scoped by the domain associated with the 
> handle service or client certificate used to formulate the 
> initial query.

Generalize this to accepting attributes scoped to domains for which the
club accepts the origin site's authority.


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

    http://archives.internet2.edu/

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