OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Draft minutes for Wednesday PM


Where you've written Connor, I believe you mean Greg (as in Greg 
Whitehead, Trustgenix).

Some other corrections inline:

ext John Hughes wrote:

> 
> 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.
> 

Actually ID-FF does not make any *specific* statement about their use. 
The normative text does state something like "other statements MAY be 
present in the AuthnResponse", and the ID-FF 1.2 Implementation 
Guidelines further explain that this is alluding to the presence 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)

I believe the issue was more about whether there was the possibility for 
*optimizing* a case where an AuthnRequest is not only asking for an 
authentication assertion, but is also explicitly querying attributes - 
in the same message. This is in contrast to the situation where one 
might get the authentication assertion in one request/response, and 
then, subsequently, query attributes.

> 
> 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
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]