| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Draft minutes for SAML F2F, Wednesday 3.30.2004 Afternoon
- From: Paul Madsen <email@example.com>
- To: "'firstname.lastname@example.org'" <email@example.com>
- Date: Wed, 31 Mar 2004 19:37:20 -0500
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
2) SP determines IDP
3) SP issues AuthnRequest to IDP, using UA as
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
-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
PM - concern is that we end up a
combinattorial number of combinations of profiles/buildings to be maintained at
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
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
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
destination site may be most common but by picking it its no longer
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
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
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
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.
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
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
RP - it identifies the party for which the assertioin was
BN- is it a change to have a MUST for
BM- are there not two ways to do
the same thing now?
Basic Processing Rules (wonkeeee
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
HL- so what else is being moved into the
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
this is not without precendent
BM- this is the other direction
BM - move that section 3.6 security
Considerations be moved out of document
PM- consensus agreeement
SC- mix and matching between bindings
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
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
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
Enhanced Client Profile
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
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
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
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 184.108.40.206 - need to add back SOAP
Header to allow a LEC to get info from the SP without having to parse
SC- should ourr samples say SAML
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
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
SC_- I'll try
- seems to be consensus that NotBefore
is not particularly useful
3 Times (ot two intervals)
Time during which:
assertion can be accepted/consumed by SP
- (2) assertion is considered
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
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
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
JL - consider this example, an attribute assertion states that an
individual carries the privilege to 'carry our high value transactions'?
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
RP - if my assertions gets pushed around within my infrastructurere,
is that forwarding/
PM; how do we make progress, what is the
RP- carefully define our use cases
MB- are we merely redefining
names or are there new requirements for time intervals.
JK- new requirement
Consensus is to add
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
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
Action Item - need text in Core
explaining notion of ValidityPeriod is tied to 1)
RL 'Bob' takes
Actioin item - add ReauthenticateOnOrAfter
JK- proposal is to define a mechanism by
which 3rd parties can submit proposed Aauthhentication Contet classes
outstanding issue is that we have SAML AuthenticationMethod and we also have
Liberty classes that subsume the SAML AuthenticationMethod, desirable to
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
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
Action Item - send out message
requesting opinions on deprecation of SAML AuthenticationMethod
Prateek & Rob
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
not add infrastructure that it both invasive and temporary.
will create more work in the next transition
Consensus - John will evaluate work
scope and come back with a recommendations
JM- proposal is that we use the Entity
terminolgy rather than iDP/SP
JM- EntityDescriptor is core element
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?
defines additional roles that are speecific to SAML (beeyond those defined by
SC- completely changed how endpoinnts are described
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
GW- deesirable to be able to validate one signature over
the complete document rather than multiple.
SC- not sure ewhat the use case
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
Securing Digital Identities
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]