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: Draft minutes for SAML F2F, Wednesday 3.30.2004 Afternoon

SSO Profile Review
SC - replaces the existing two profiles (POST & artifact). Tried to define an abstrtactt sequence diagrram modeleling the abstract message exchanges
Six abstract steps
1) UA access SP
2) SP determines IDP
3) SP issues AuthnRequest to IDP, using UA as intermediary
4) UA authenticates to IDP
5) IDP issues Response message to SP, through the UA. Message will contain at least an Assertion
6) SP grants access or nott
SAML 1.1 starts at Step 5 above
-Intersite Transfer Service exists for both ends, IDP and SP
-Single-SignOn Service is where the AuthnRequest (or artifact) gets sent by the UA
-AssertionConsumer Service is where the AuthnRespone (or artifact) gets sent by UA
-RelayState should not contain URL
PM - concern is that we end up a combinattorial number of combinations of profiles/buildings to be maintained at SP/IDP
SC- exists in Liberty. No value judgement, some people believe we need differernt mechanisms to do the same things
PM- in SAML 1.1 we had very definite mechanism
SC- not a technical issue,
SC-  4 combinations are from 2x2 (by value/by reference and both directions)
EM- what is the value of this abstractness
SC- important to define what are the requirments at each step
CC- this ia good description of whats actually happening
EM - does thtis correspond to 'Destination site'
CC- not necessarily, this is me browsing to the SP rather than being sent to the SP from the IDP
EM - destination site may be most common but by picking it its no longer abstract
JH - there was a gap in SAML 1.1
SC - completely encompasses what SAML 1.1 defined
EM- so, for conformance, what do you have to support. Is the profile still the unit of conformance?
PM - we had two concrete ways of pushing an assertion around,
SC - we are both combining the two old profiles and adding new message flows
Protocol Profile - this is where he actually profiles the protocol (the request/response as defined in Core) profiles how the protocol can be used within the SSO profile)
EM - this can't be called a profile
JL - this is the original definititon of 'profile'
SC - Sections 3.4.1 and 3.4.2 consttain down AuthnRequest and Response
For AuthnRequest, the only constrain is that there cant be a Subject. Only relevant if the SP already knew who the User was -as might be possible for reauth
PM- don;t want to have to build a responder with logic for reauth
CC- expectation is that the subject is the same
CC - probably not clearly documented what happens if the SP sends a reauth request and thhe iDP creates an assertioin for a different Principal. SP has to know to look at the Subject.
SC - reasonable to allow the SP to indicate the Subject for which an Assertion is being sought
PM - consensus is to remove the 'MUST NOT' and provide guidance prose.
TN - can i do these (AuthnRequest and Response) separately?
SC- yes, this is conformance question. therer is 'source-site first' so you do not ned to have an AuthnRquest.
cC- this puts alot more weight on the conformance doc because the conformance doc is going to define what is the required flow.
fH - in the prefvious SAML profiles all the details were there
SC- I think you are oversimplifying some of ID-FF.
SC- pushing back on the assertion that there are now all sorts of new things to be tightened up in Conformance.
CC- If I read this documenet, I'd assume I have to implement AuthnRequest 3 ways (re-direct, POST, and artifact), and 3 ways for Response.
SC- Response Profile more extetnsive than that for AuthnRequest
IR - the restriction that there be only a single AuthenticationStatement is to strict,
SC- OK (will change)
Action  Item - relax  AuthenticationStatement Occurrence
PM - I'd like to see a line saying that the Response can carry AttributeStatements
TN - if there are multiple responders, are they all constrained to meet the conditions?
SC- Yes, the AudienceRestrictionConfition names the recipient, which could be a high-level entity
RP - it identifies the party for which the assertioin was created.
BN- is it a change to have a MUST for the AudienceRestrictionConfition/
SC- yes
BM- are there not two ways to do the same thing now?
SC- disagree
Basic Processing Rules (wonkeeee section)
SC- disclaimer- you may not like this but what I said was, to try and avoid two signature, the model is to stick everything in the assertion and sign there.
PM- proposal is to remove the signature from Response?
BM- we are dispensing with thte layering model to avoid multiple signatures.
CC- SPs have to write code to look for signatures, much better to have one place to look
SC- Response serves no role other than a Root element
CC- have to put things like CorrelationID where they can be integrity protected
FH- so we're moving protocol information into the assertion for performance reasons?
HL- so whats the threat, if I don't have sufficient confidence ...
HL- an assertion means what it means independent of how i got it, worst case is I get a false rejest
IR- if I make an Artifactrequest and somebody can replay a different Response by playing with the INResponseTo attribute then the Artifact could be assocaited with another user.
SA- co0llapsing the layers for performance reasons seems very sad
cC- I'll take the hit for the performance gain
HL- so what else is being moved into the Assertion?
SC- .........
SC- the point of the BindingCondition is a hack, its everything you would normally put in the Response but can;t because it needs to be integrity protected by the signature over the assertion
JL- this is not without precendent
BM- this is the other direction though
BM - move that section 3.6 security Considerations be moved out of document
PM- consensus agreeement
SC- mix and matching between bindings and profiles
PM- need an owner to define a limited number of ways to push an assertion from one point to another
SC- not just pushing the assertion
PM- just because we can do it 3 ways doesn;t mean we have to define them as SAML approved. Need to pull their weight. Somebody needs to drive this discussion. So who is going to this?
Action Item: Prateek takes ownership of driving a discussion on limiting combinations.
EM- obvious way it to make one of each pair as mandatory to implement
SC- I don;t want artifact to be the mandatory one
PM- we need to discuss this
jK- also oneed to distinguish between what is mandatory to implement and what is sensible to implement. Shouldn;t give people the impression that you can take a piece from here and there and expect things to work
EM- sparse matrix needs to be determined.
Enhanced Client Profile
 Frederick Hirsch
FH- neeed to oetermine how to reflecct/incorporate Scott's proposal
FH- thte way that ECP works is that the SP sends an AuthnRequest to the client, and the client knows how to get to the IDP
FH- ent through doc summarizing recent mods
jK- Device should not have to look into the payload to see where the Response should be sent
CC- ran into a problem in Liberety, the Response should only be sent to the address specified in the Response, Shouldn't pay any atttention to what might have been specified in the AuthnRequest
SC- only useful for error responses
FH- needs to be renamed
JK- might be defined in PAOS, may not have the leeway to rename, must clarify usage
FH- also changed messageId, recommended that it be not used, but if used, rersponse must have correlation
Section - need to add back SOAP Header to allow a LEC to get info from the SP without having to parse AuthnRequest.
SC- should ourr samples say SAML 2?
EM- just saml annd samlp, should be version agnosttic
FH- related to that, are we doing SOAP 1.1 or 1.2?
EM- assume SOAP 1.1, on the issue list
CC- do we have a standard for namespace prefacing
JK- may not have been implemented
EM- pretty good
FH- changed authnResponse to Response- consistetnt with everything else

PM;- how to proceed?
FH - what are the requirementns?
SC_- I'll try
- seems to be consensus that NotBefore is not particularly useful
3 Times (ot two intervals)
Time during which:
 - (1) assertion can be accepted/consumed by SP
 - (2) assertion is considered valid
Time at which:
 - (3) a session initiated as a result of the profile should be killed or refreshed
Scott's intterpretation of 1.x is 1 and 2 are the same and extremely short and 3) was unaddressed
JL- in X.809 it is 2) that is addressed
HL- if you look at the revocation reasons its clear that X.509 combines 1) and 2), the analogy breaks down
CC- my interpretation is that a SAML assertion says that a statement cacn be assumed to be valid only at the time - there is nothing in thte assertion that would indicate a longer lifetime
SC- I think of 1) as having more to do with how its being passed around as opposed to an intrinsic qualityy of the assertion, and therefore 1) belongs on the Response
Consensus opinion was that 1) does belong on Response rather than Assertion.
MB- its the SP that really needs to specify the lifetime policy
CC- but the IDP's requirements feed into this decision
JL - consider this example, an attribute assertion states that an individual carries the privilege to 'carry our high value transactions'?
PM- how long can you depend on the information is the key?
CC- validity is not just the length of time
SC- is there any sense in which the spec makes it the case that you shouldn't make use of the attributes after a given time? When do I go back and say, 'is this still true'?
BM- the mechs that X.509 provide are the CA promises that it will keep track of the information within the cert so that an RP can ask it, and that it will respond to revocation requests.
SC- I want to push back on the statemenet that assertions cant be forwarded, if not there is no point in signing
RP - if my assertions gets pushed around within my infrastructurere, is that forwarding/
ALL- no
PM; how do we make progress, what is the plan?
RP- carefully define our use cases
MB- are we merely redefining names or are there new requirements for time intervals.
JK- new requirement is ReauthenticateOnOrAfter
Consensus is to add ReauthenticateOnOrAfter
GW- there is a use case in the Liberety Web Service world, the SP gets an assertion from the IDP and this assertion can't be short-lived because it needs to be used in subsequent Discovery Requests
PM- there is a suggestion that the 'forwarding' use case. a solution is that the issuer of an assertion is free to ignore the time constraints that it placed.
Action Item - Document the solution proposal by which issuers are not constrained by
 Keep Open
Action Item - need text in Core explaining notion of ValidityPeriod is tied to 1)
 RL 'Bob' takes action
Actioin item - add ReauthenticateOnOrAfter
 Scott Cantor
 John Kemp
JK- proposal is to define a mechanism by which 3rd parties can submit proposed Aauthhentication Contet classes
JK- outstanding issue is that we have SAML AuthenticationMethod and we also have Liberty classes that subsume the SAML AuthenticationMethod, desirable to harmonize them
JK - initially thought that SAML AuthenticationMethods were simple and we could do a simple 1-to-1 mapping, not that easy.
JK- asking the group whether or not he should do the mapping?
EM- would changing the AM URIs to classes change the senmantic?
JK- probably not
JK- proposal is to stick with existing mechanism and defer the real work to another time
PM- why are we committed to keeping SAML 1.1 AM?
SA- so why not make it a choice
SC- what worries me are the facilities within AuthnRequest by which an SP can indicate its requirements
SC- parallel issue is should we not be ccleanning up the existing SAML 1.1 AMs
SC- asking John Kemp 'do you want to make the schema changes?'
Action item - make schema changes so that AM and AuthContext are parallel choices
 On hold
Action Item - send out message requesting opinions on deprecation of SAML AuthenticationMethod URIs
 Prateek & Rob
EM- confused
JK- happy if the group decides that we should do the single mechanism,
EM- the tesmporary mechanism is to make changes that everywhere one occurs, the other can occur. I'd rather
not add infrastructure that it both invasive and temporary.
SC- it will create more work in the next transition
Consensus - John will evaluate work scope and come back with a recommendations
 Jahan Moreh
JM- proposal is that we use the Entity terminolgy rather than iDP/SP
JM- EntityDescriptor is core element
PM- need to clarify relationship between ProviderId and Issuer
JM- entity cann act in one of roles, an abstract RoledescrtiptorType. One concrete type is SSODescriptorType to distinguish between IKDP and SP.
PM- do we still need PDPDescriptor? Given that we are distancing ourselvees from this
SC- not a large amount to worry about
PM- what are the conformance implications?
SC- defines additional roles that are speecific to SAML (beeyond those defined by Liberty)
SC- completely changed how endpoinnts are described
JM- Prateek, you had also asked about AttributeConsumerURL to allow a consumner to indicate what attributets a consumer might want
SC- I deefined how this would work on the consumer side, not the provider
JM- put together text arounnd Digital signatures, a bunnch of different elements can be individually signed. Need guidance on what should be done. Jahan has recommended that all elements be signed individually
GW- deesirable to be able to validate one signature over the complete document rather than multiple.
SC- not sure ewhat the use case would be
JM- softter recommendation is that at least one of RoleDescriptor, or EntityDescriptor or EntitiesDescriptor be signed
GW- inclination would be to havee a single signature at the top level.
PM- signing model should suppor the distribution model.
jM- metadata exchangee will be accomplished through well know URLs eexchanged out of band
SC- subsequent to preeevious F2F, Neustar has indicatted that they would like to see the DNS mechanism (as defined by Liberty) supported.
PM- conformance won't make these requireed.
Paul Madsen
e:  p.madsen@entrust.com
p:  613-270-2632
c:  613-799-2632
Securing Digital Identities
& Information

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