Shibboleth Developers

Phone #:  (800) 541-1710
Pin #:  0142203

Agenda:

1) Current programming issues/questions

	- I'd like to review the status of the  apache 2 version 
(altho I seem to  recall Derek mentioning that  he would be missing 
this call)

2) Continue discussion of a DRAFT non-web-browser profile, describing 
how a client (other  than a web browser) could obtain a SAML Authn 
and Attribute Assertions and present them to a target.

http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Version-2/Profile-Non-Browser/draft-carmody-non-browser-profile-01.html

This is still a DRAFT -- some sections aren't even filled in at this 
point. Its modeled on the the SAML Bindings and  Profiles doc:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

do a FIND  on 07-Sept-2003 , and then click on "Bindings and Profiles".

This 01 version contains significant changes from the previous -00 
version, based on comments made during last week's  call. Major 
changes include:

1) the addition of an Issues section, to collect questions that are 
still outstanding, or implications that must be remembered.

2) explicit introduction of both the PUSH and PULL use cases, and 
message sequences to support them.

3) improved description of the message exchanges. There's still 
detail missing, but the description of the flows and players 
(including the client, authn authority, attribute authority, and 
destination) now have the right structure.

4) The exchange between the client and the SAML Authentication 
Authority is described  in much more detail.The client now uses the 
SAML-SOAP protocol to authenticate itself.

5) The Threat  Models section is still  empty, but I expect to be 
able  to crib major amounts of text from  the SAML Profiles doc.

6) a STRONG RECOMMENDATION that  implementations use the 
holder-of-key Confirmation Method, and a rough description of how it 
would be used. As I understand this method (and I might still be 
completely mistaken), this approach provides the relying party with a 
much  higher level of assurance that the received assertions do, in 
fact, refer to the client..

There was a suggestion last week to separate the two issues of a) how 
to obtain  the assertions, and b) how to use them. I think this draft 
contains more information  about a) than the previous version. It 
also addresses subject confirmation (see 6) above), and (implicitly) 
re-use for multiple recipients (both of the holder-of-key 
confirmation methods would prevent re-use).

this draft doesn't yet specifically discuss what a client can do with 
the assertions (and can't do), or contain any analysis/comparison of 
the issues related to the PUSH and PULL models.

But, I'm looking forward to comments, reactions, and pushback on this 
new version  (-: