Draft minutes for Wednesday PM

["John Hughes" <john.hughes@entegrity.com>]

W-2a – SSO with Attribute exchange (Prateek)
******************************************

Several models of use.  When NameIdentifier is passed – then attributes are passed

<AuthnResponse> may carry assertions with attributes statements.  However ID-FF does not explicitly describe this use.

Attributes could be attributes from a second source – for example obtained from a LDAP directory – or a collection of.  

ID-FF 1.2 text does not make any statements on the use of attribute statements.

Proposal revise text to explain that attribute statements may appear in AuthnResponse.  However there is an issue re attribute life-time concerns

Prateek: question are we happy with this:
Rob: sees no problem with solution
Scott: sees critical that time validity information is needed.

General discussion on whether validity period of attributes is useful or serves any purpose.

Prateek:  question do attributes need a separate “time to live” values?
Hal: need a “milk”field  – “use by”

ISSUE:  resolve barer token versus assertion versus attribute statement validity periods

Other aspect to adding attributes is use of pseudonyms.  Still return attributes – but NameId is pseudonym.  

Scott:  could this be what ID_FF calls affiliation?
Prateek: However in this case there is no account linking
Prateek:  need to clarify the use cases vs the ID-FF federation use cases
RL Morgan:  need to sort out naming space – i.e. real names
Scott:  need to start examining the pair-wise case of the relationship
Prateek: key is to make sure Service provider not be involved in account linking/federation – rather the powerful Identity Provider.
Prateek: privacy issues depending on the given federation use case
Conor: If look through liberty spec
no normative text re account linking

ACTION:  Prateek to describe new use cases – for liberty guys to review (as current Liberty specs may cover those that Prateek is raising)

Prateek: question do we need to consider AuthnRequest should carry attribute query?
Tony: do we need to model the run time querying of attributes?
Prateek: not seen a business case for this
Scott: what other things could we add?  There are issues going through a browser (ie. too large for URL)

Other issues:  encryption of attrs; meta-data; use of std LDAP attribute names.


W4 Profile enhancements for Meta-Data (Jahan)
*******************************************

Waiting until Meta-data specs are stable – then go back to enhance profiles


W3 Meta-Data (Jahan)
************************

No work since October.  Scott did a review of Liberty 1-2 meta data.  Proposal to produce new draft – based on liberty meta data.  Perhaps strip out those features not required for SAML

Scott:  need to consider whether features are stripped out – as some people are using them.

Prateek: are the SAML roles considered in spec?
Scott:  No.  Need to make sure meta data is extensible to cover unknown future SAML work.
Scott: Meta Data needs to consider perhaps roles for SAML 1.1.  (versioning)

PROPOSAL:  to consider ID-FF .1.2 meta data as basis of SAML 2.0 work – subject to removing any liberty web services specific.

APPROVED: unanimous


W8 – Authentication Context (John Kemp)
*****************************************

Taken a documented use case on the list.  Means to get authentication characteristics – beyond authentication method.  For instance policy and operational aspects.   Schema provided to express statements and whether it conforms to a particular classes.

Tony:  seems to be a brand new mechanism to do this – rather than a generalized approach for this and meta data – and other stuff.

Connor: means to take existing authentication method to the next level in expressiveness.

One use case is AuthnResponse will have a URI pointer to this, rather than it carried around. Also can issue it in a request to say that the authentication need to met this policy.

PROPOSAL: to take document as basis for work item.  
APPROVED: unanimous


W9 – XML Encryption  (Hal)
*******************************

Encrypt Assertion, NameIdentifier or Attribute
Not proposing to be able to encrypt it all – rather just these defined.
Excluded:  arbitrary encryption; encrypted AttributeValue (i.e. have to encrypt to do the whole thing) Encrypted SubjectConfirmation

General approach:  
-	nameIdentifer and Attribute – Scott’s select technique
-	assertion – replaces with encryptedData and optional Encrypted Key (if using PK)

Rob:  what about requests?

Hal: not as critical to develop this – this as we now have SOAP encryption – and other mechanisms in the transport layer

Question: which way to go re encryption techniques.

Hal: should we consider to encrypt AttributeDesignator in requests?
Connor: do u have to separately encrypt each attribute?
Hal: yes
Scott: perhaps we should support encryption of individual statements?

ACTION:  Hal to produce text to describe 3 use cases for SSTC to consider.


W14 SAML Server Trust (Jeff Hodges)
***********************************

Liberty produced a document (by John Linn). Liberty have submitted document to ID-FF – as possible basis for SAML 2.0.

Possibly add into Security Considerations and/or implementation guidelines

John Linn: trying to tease out of notation of direct and indirect trust relationship re authentications and business relationships.  Provides general guidance on trust management in a technology neutral way.

Rob:  what does it miss for SAML?
John L: believes the content is very generic.
Scott: who ever signs up to it will have to address what’s missing
John K: simplest way is to have standalone doc
Jeff: something he could do.  

ACTION: Jeff Hodges to reformat it and recast into SAML

Tony:  will need to review later to decide whether should be included.  AGREED


W15 Delegation and Intermediaries  (Scott and Bob Morgan)
************************************************************

Proposal: to provide a Kerberos ST to the intermediary as a SAML attribute (either as regular SSO or requested).  

Tim: would want ability to carry multiple ST

John L:  do we need ability to have a confirmation method for an attribute?

Bob:  Need to send ST encrypted under long term session key – i.e. usual Kerberos integrity/authn overhead structure.

Tim: just trying to transport delegated credentials?  
Bob: Yes. 
Tim: Believes good solution

Scott: do we need to handle multiple intermediaries?  Doesn’t think so - we want to go down that slippery slope – given that timescales.

Tim: perhaps contact IETF about having a “SAMLinit” – another pre-authentication method.

Ron: perhaps use SubjectConfirmation to carry ST – rather than building a special case

Scott : this use case may need AuthnRequest enhanced so that it could indicate the subject that it needs the assertion back for (and the subject name is different from than for the AuthnRequest).  Has a similar feel to that in the Kerberos Use case heard earlier.

Scott: proposes to extend so a more generalized mechanism means to request and manufacturer assertions.

Ron: is there means to get an assertion back with a given subjectConformation method?
Scott; believes there should be
Ron:  perhaps supply back the ST in the subjectConfirmation data
Ron: have we time to do it?
Scott:  Proposes to change AuthnRequest to handle some of this.
Ron: would like to help

PROPOSAL:  get basic integration of AuthnRequest/Response and then look at the various use cases to see how they can be integrated in.  (Scott)

W6 – Proxied SSO (Scott)
**************************

ID-FF addresses how to chain SSO protocol across multiple identity providers.

Couple of use cases.

Liberty used authentication context to carry a list of identity providers.

Connor: Allows a use case where for instance OASIS is the proxy IdP and that would proxy through to individual companies IdP

PROPOSAL:  that the elements in AuthnRequest/Response to support proxying are maintained as ID-FF as goes forward.

Afternoon session closed:  5pm