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
- From: Paul Madsen <p.madsen@entrust.com>
- To: "'security-services@lists.oasis-open.org'" <security-services@lists.oasis-open.org>
- 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
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
Scott
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.
HL-
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 3.3.4.1 - 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
################################################
Validity
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
################################################
AuthnContext
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
################################################
Metadata
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
p: 613-270-2632
c: 613-799-2632
Entrust
Securing Digital Identities
&
Information
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]