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

    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

e:  

p:  613-270-2632

c:  613-799-2632

Entrust

Securing Digital Identities 
& 
Information

http://www.entrust.com