[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]