[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Consolidated minutes for SAML V2.0 f2f #5 - June 15-17, 2004
|
Consolidated minutes for SSTC SAML V2.0 F2F #5, Tues-Thurs
15-17 June 2004 ====================================================================== Summary ====================================================================== Votes: ·
None - quorum not achieved New Action Items (Note that this list simply consolidates
the items in the raw minutes that were highlighted as AI’s. There are
additional items that folks said they would do that are described in the
minutes. Everyone should review the raw notes for any items they agreed to
take on): 1. Editors to
resolve submission process for additional Authn Context classes / Bindings /
Profiles 2. JohnK and
Scott to move Authn Context Declarations to XML Schema centric approach 3. Scott to
ping Peter for additional text, subsequent to that there will need to be a
review to ensure that the appropriate SHOULDs etc are there. 4. Scott to
reorganize section 4 (Metadata) to clarify 5. Scott to
clean up the text around the different types of profiles in Section 1.1 6. investigate
profile designator for statement and query - potentially allowing for endpoint
metadata 7. Scott to
talk to RL Bob (re: BER & DER issues in LDAP/X.500 profile?) 8. Prateek to
ping John H for clarification (re: UUID’s being used with attribute
values) 9. Scott to
incorporate into document. include reeference to Appendix A. (re: XACML
profile) 10. Need
clarification as to what is the target namespace for the DataType element? (re:
XACML profile) 11. Paul Madsen
to take the exec overview document 12. Scott will
investigate use of wiki on Oasis site 13. chairs to
put item regarding errata process on the concall agenda 14. (Jeffh)
Resolve status of RFC (re: syntax of UUID as URI) 15. (Scott) to
document the well-known values for the DCE attribute name 16. (Scott) Will
fix spec. to be more precise about use of encryption with name identifiers (per
discussion on PKI-based attr profile) 17. Rick R. (and
customer) should read and accept the OASIS IPR policy for document submission 18. (chairs)
discuss + resolve general approach to new profiles 19. Jeff to add security
context to Glossary 20. Jeff to help
with sequence diagrams for profiles 21. Rob to
enumerate the implementation declarations/claims of interest. Prateek and Scott
will contribute. 22. Hal will
look at OneTimeUse text again and attempt to clarify 23. John K. to clarity
text on 909-911 on SessionIndex 24. John K. to
look up why SessionIndex is required 25. Scott to o
propose alternate text for section
3.2.3.1 o
strike 3.2.3.2-3.2.3.4. o
rewrite 3.2.2.3-3.2.2.5 26. Hal to get
expert advice on how to prevent caching by proxies and user agents New Issues:
Existing Issues:
====================================================================== Raw Notes ====================================================================== [Steve Anderson begins as minute-taker]
·
Conor P. Cahill AOL, Inc. ·
Hal Lockhart BEA ·
Rick Randall Booz Allen Hamilton ·
John Hughes Entegrity Solutions
(dial-in) ·
Paul Madsen Entrust ·
Dana Kaufman Forum Systems ·
Irving Reid Hewlett-Packard Company ·
Michael McIntosh IBM ·
Scott Cantor Individual ·
Prateek Mishra Netegrity ·
Frederick Hirsch Nokia ·
John Kemp Nokia ·
Charles Knouse Oblix ·
Steve Anderson OpenNetwork ·
Darren Platt Ping Identity (dial-in) ·
John Linn RSA Security ·
Rob Philpott RSA Security ·
Jahan Moreh Sigaba (dial-in) ·
Jeff Hodges Sun Microsystems
·
Gavenraj Sodhi Computer Associates -
Lost voting status after 6/15/2004 F2F ·
Emily Xu Sun - returned from LOA
6/14
·
Quorum not achieved
- John Kemp walking thru Authn Context doc (draft 5, PDF) - discussion of need for process for registering new
context classes - Hal: process should just verify
that doc is in right form, rather than verifying technical
merits - JohnK: line 4849, copied from
other SAML docs - Conor: do we need sanity check for
new classes? - Paul: thinks so - Conor: in - Scott: sees difference in
accepting for web site, and accepting into core doc set - Jeff: let's not rathole on this
now, just leave this section (5.5) TBD - JohnL: don't want to appear to
make commitment to post any submission on website - JohnK: proposed text? - Scott: if we change this, we need
to change other docs - Conor: OK for anyone to submit
anything, as long as we categorize sanctioned vs. not sanctioned - Hal: IPR issues with submissions
... but not going to rathole on that now - Prateek: thinks the stated
guidelines are helpful - [ACTION] Editors to resolve
submission process for additional Authn Context classes / Bindings /
Profiles - Conor: care should be taken to try
to define new submissions as member of existing class, rather
than entirely new class - JohnK: implemented Eve's suggestion: Authn
Context Statement -> Authn Context Declaration - need to clean up capitalization - JohnK: implemented former Authn Method as
Authn Context Class - Paul: noticed reference to Authn Method
that needs to be updated (line 121-122) - JohnK: will fix - JohnK: (line 2827) declarations must
conform to a class - discussion of formal XML issues around
AuthnContextDeclaration - taking example of Password (line 3712,
with real example starting on 3769) - Scott: this is not any formal use of XML
Schema that you would ever find - it's a documentation use - Prateek: and the reason for not putting
this in a schema-centric model was expedience? - Paul: (originally did this work in - Jeff: we're talking about putting
machinery into the schema that would enforce lines 3797-3799? - Scott: yes - JohnK: as well as lines 2827-... - Scott: doesn't think this is a big effort,
and even willing to do the work - discussion of derivation by extension vs.
derivation by restriction - Conor: has received feedback, falling into
two cases - authn context has to be explicitly
recognized - authn context has to be "at
least" X - [ACTION] JohnK and Scott to move Authn
Context Declarations to XML Schema centric approach - Rob: schedule is tight, so can this work
be done in next few days? - JohnK/Scott: yes, might have schema by
Thursday - JohnK: Kerberos (line 3925) - not all interested parties present - principal authentication mechanism is
represented - JohnL: confused by "Kerberos
Protected Transport" - JohnK: was going to do this, but didn't,
so should just be "Kerberos" - Hal: thinks right way to do this is to
treat the initial handshake (preauth, PKI, whatever) as a
property of Kerberos - Scott: the other case was this web use
case, where principal sends password to server, who happens to
use Kerberos to verify it - called
"PasswordProtectedTransport" (3819) - don't want to confuse this with
"Kerberos" - Jeff: suggests
"PasswordOverProtectedTransport", because "PasswordProtectedTransport" is
misleading - - now AuthnContext is optional -- is this a
problem? - Scott: could make it required - also, none of the 1.0 URIs should be used - JohnK: (line 4430) Secure Remote Password
modeled after Kerberos class - Rob: line 4429, parenthetical is confusing - is reference to old value - Scott: move to migration guide - JohnK: SSL/TLS Certificate Based Client Authn - Rob: same comment, move old URI to
migration guide - JohnK: X509 Public Key - Rob: mixture of old approach
("am" in URN) with new ("ac") - JohnK: will strictly use new - - needs to be clarified - JohnK: all of these public key methods are
very similar - Scott: (line 4712) not sure what
XKMS has to do with user authn - - but that seems to belong inside
X509 class - Scott: slippery slope, having this
as its own class - resolution is to drop it as a
class - Rob: add to migration doc - Jeff: suggests that we maintain an
issues list for authn context - we want to get doc out the door,
but we don't want to lose issues for future work - Rob: we can track in current
issues doc - [ISSUE] Deprecation/removal of
XKMS authn context class - Paul: prefers something other than
"keyAuthn" (ex line 4817) in all public key classes - group prefers "keyValidation" - Rob: Table of Contents needs to be regen'ed
- Scott: walking thru Metadata doc (draft 06, PDF) - changes - mainly reformatted doc to match
template - made some changes for uniformity - not many others - Version in EndpointType (line 165) - profiles have changed in 2.0, so they're
really the first version of their respective forms - are the same - Scott: still thinking on what Version means in
this context - we've never versioned a profile before - [ISSUE] Versioning in Profiles and Metadata - Scott: has considered moving away from
element-based approach to metadata, in favor of
attribute-based - but makes XPath searching more complicated - Jeff: solution could be to have separate
element for each profile supported, and to include Version info
if relevant - Scott: "families" of profiles will
be seen in Profiles doc - [discussion ...] - [resolution] drop Version, and any subsequent
versions of profiles will result in new metadata elements - e.g., if we create V2 of SingleLogout profile,
we'll either create a new SingleLogoutV2 element in
existing metadata namespace, or create new metadata namespace - issue still open regarding versioning profiles - continuing with Section 2.3 Root Elements - <EntitiesDescriptor> is just a container - <EntityDescriptor> is really the unit of
metadata - beneath that, can have either
AffiliationDescriptor or (more commonly) a sequence of one or more RoleDescriptor
(or a derivation) - AdditionalMetadataLocation allows implementations
that support both ID-FF and SAML 2 metadata to publish both
forms, cross- linked - really, is a form of versioning - [ISSUE] How to represent support for attribute
profiles in metadata - Scott: on SP side, added attribute indicating
desire to have assertions signed by IDP, independent of profile
requirements - Conor: what about on IDP side, stating that
assertions will be signed? - Scott: didn't do that, but can - Prateek: more generally, can't endpoints have way
to state what optional features they need or will provide? - Scott: will require more thinking - Conor: difference between what is wanted vs what
is accepted - Scott: the reason signing got special attention is
overhead, moreso than security - KeyDescriptor (line 503) - Scott: recollection is that EncryptionMethod
speaks to encryption OF the key rather than encryption
BY the key (which is why it states it in the doc), but needs to
verify - [ISSUE] Verify purpose of EncryptionMethod in
KeyDescriptor in metadata - SSODescriptorType (line 536) - Scott: "ArtifactLookupService" doesn't
sound right - "ArtifactResolverService"?
"...Dereference..."? - needs to be consistent with related protocol components - winner: ArtifactResolverService / ArtifactResolve
/ ArtifactResolveResponse - [ISSUE] AssertionConsumerService ID attribute is a
string, but attr name suggests xsd:ID type - change to "Index"? - Indexes are usually thought of as numbers - can restrict values to be numeric - [RESOLVED] - [OLD ISSUE] some wanted to add location hinting to
artifact, to support multiple artifact resolvers - ArtifactResolverService will resemble AssertionConsumerService, including Index - Artifact format will include space for this Index - [RESOLVED] - [ISSUE] SSO profile is different in how role division
is split across request response - In other profiles, request and response were
combined - doesn't think it's a problem, it's just
different - [ISSUE] SSODescriptorType shouldn't be a base - Scott: how about eliminating the type, and move
the components into SP and IDP descriptors? - Jeff: we need to determine what
must be changed now vs. what can we live with for now and
publish - Rob: could rename SP and IDP descriptors
to SPSSO... and IDPSSO... - Scott: agreed - Scott: continuing with AttributeRequesterDescriptor
(line 712) - the IsRequired attr inside
RequestedAttribute allows the expression of necessary attrs in SSO - If we add indexes to
AttributeRequestingService, you can provide a reference into metadata from attribute
queries - AttributeRequestingService was previously
called AttributeConsumerService, and someone
specifically asked for name change - Scott: dislikes "Service" in
"AttributeRequestingService" - [ISSUE] Need new name for AttributeRequestingService [Paul Madsen taking over minute-taking] June 15, 2:45 - 5:00, Minutes --------------------------------------------------------------------------- Metadata tail-end John Linn raises concerns about the complexity of some of
the metadata mechanisms. Scott asserteed that it was in there becausee Neeustar has
implemented it and they need it in. Need to make sure that text makes clear that this is
optional. Jahan - I had thought we had decided to forgo the DNS stuff Scott - we did, but a member pushed back. [ACTION] Scott to ping Peter for additional text, subsequent
to that there will need to be a review to ensure that the appropriate SHOULDs
etc are there. [ACTION] Scott to reorganize section 4 to clarify Section 3 – Signatures Scott suggests that we create a profile of XML-Sig for
signing metadata elements. might just be stating that you're signing one of
these three elements etc --------------------------------------------------------------------------- SAML 2 Schedule June 15: V2.0 F2F in June 22: Review updates since f2f. June 29: Both Prateek and I will be out – anyone want
a focus call this week? July 6: All specification suite documents must have
incorporated all input from the list and F2F #5. Note that this gives us 3
weeks since the F2F to complete all document changes and to resolve issues and
action items. This now begins sort of a pre-last-call deadline for final
input. Depending on how well things come together, we might possibly start our
TC last call here, but we opted to allow another week before doing that. July 13: VOTE to start 2-week committee last call period
(includes external public review). July 20: Review any last call input to date. July 27: Cut-off date for TC last call input. All outstanding
issues have been dealt with according to the last call process. The specs now
become our "candidate” Committee Drafts and the TC addresses any
outstanding non-normative editorial issues August 3: VOTE to move spec’s to “Committee
Draft” status (requires YES votes from 2/3 of ALL voting members). VOTE
to move CD spec’s into 30-day Public Review for OASIS standardization
(majority vote). Edit doc’s for CD status. Notify TC admin of the start
of formal Public Review. September 7 (first call following 30-day public review):
Make sure all public review comments have been properly dispatched. Final
editorial changes must be complete. VOTE to re-approve spec’s as final
Committee Draft and VOTE to submit to OASIS for standardization. September 8-15: Complete all submission paperwork. All
submissions for an October voting period must be complete by September 15. Rob's biggest concerns are around outreach docs ---------------------------------------------------------------------------
Profiles Discussion sstc-saml-profiles-2.0-draft-10-diff.pdf To cover -Attribute profiles -Connecting to Metadata --------------------------------------------------------------------------- Attribute Profiles Prateek took us through the recent changes to the Profiles
doc docussed on Attributes. A new section provides a set of guidelines for defining
attribute profiles as well as 3 three specific attributee profiles 1) Basic Attribute Profile 2) LDAP/X500 3) UUID Jeff Hodges asked for clarification as to whether the
profiles was for the reequest/response or for the designator/values? Scott
suggested that using 'query' in the intro text on line 125 was misleading as it
implieed something to do with the request/reequest protocol - text should be
expressed instead in terms of attributedesignator and attribute. Prateek suggested that the implication on AttributeeQuery
should be noted John suggested that Seection 1.1 Profile Concepts should be
moved before Prateek's text and then refereenced. [ACTION] - Scott to clean up the text around the different
types of profiles in Section 1.1 Section 7.1 Provides a checklist of items that MUST be addressed by each
attribute profile. Scott says that bullet 2 within guidelines 'Unique URI to be
used for the NameFormat attribute of the <saml:AttributeDesignator>
element' - NameFormat is inappropriate. A profile may need an identifier but
should it go on the designator? May suggest that we need an new element more at the protocol
element. Resolution1 - we should retain NameFormat for its original
use. Do we need to carry the profile name as part of the
attribute or attributedesignator? What is the unit at which it makes sense to
specify profile. Discussion as to the relevance of being ablee to specify
profile on specific attributes. Conor - are we accounting for XML attributes? Yes. Rob- propasal that we be able to describe profile at the
statement and query level. [ACTION] - investigate profile designator for statement and
query - potentially allowing for endpoint metadata. Scott asserts that agreeeing on what to go in
attributedesignator and attribute elements is a subset of a whole bunch of
things you have to come to an agreement upon for attribute sharing. Prateek
acknowledges this but questions whether we want to think about this right now.
Agreement. Rick - two levels of profiles Basic Profile Jeff - why does xsi:type neeed to be present? To know
whether its a datetime or string etc LDAP/X.500 Names constrained to come from URN oid namespace (following
Bob) Scott - I pushed back originally on Bob's proposal. No
longer an issue. John - any BER & DER issues? Section 7.3.3 says the canonical
representation is an octet sequence. Scott- this was not Bob's intent. So what should we do? What did DSML do? NA. [ACTION] - Scott to talk to RL Bob. UUID Profile Intent is that UUIDs occur as attribute names. Not so clear
whether there are values. [ACTION] - Prateek to ping John for clarification. --------------------------------------------------------------------------- XACML Profile Led by Prateeek Submission from XACML TC to add to attributee profile
section 'SAML Attribute Assertions may be used as input to
authorization decisions made according to the OASIS eXtensible Access Control Markup Language (XACML)
standard specification [XACML]. Since the SAML Attribute format differs from the XACML Attribute
format, there is a mapping that must be performed. The OASIS XACML TC has defined a Profile for
doing this mapping [XACML-Profile], but that Profile imposes constraints on the meta-data provided
with the SAML Attribute. This Profile describes those meta-data constraints' ACTION - Scott to incorporate into document. include
reeference to Appendix A. ACTION - Need clarification as to what is the target
namespace for the DataType element? Scott is conceerned that the profile doesn't say anything
about what can go in the XML instance. Hal doesn;t see it as a concern. --------------------------------------------------------------------------- From: John Kemp [john.kemp@nokia.com] Minutes 2004-06-16 (morning) SSTC F2F -------------------------------------
Arch overview ------------- summary of overview doc looked good. some things missing - use of queries - federation + other protocol profiles (logout, RNI etc.) - discussion of general background to saml (web services
work, ID-WSF, WSS STP) discussion of 11-20 differences as separate document instead
of as part of overview - only a bulleted list migration + what's new combined in document exec overview targetted to journalists + CEO (Paul Madsen
volunteers to take this document) AI: Paul Madsen to take the exec overview document rob: when can we get first draft of tech overview? john hughes: 22nd July (JohnH is on vacation after) hal: publish first detailed outline sooner prateek: id-ff 1.2 arch overview could be used as source
document conor: use as much as is useful - it was contributed work to
SSTC JohnH: next version of ppt on 22nd June prior to call? rob: discussion on schedule yesterday. these docs are not
part of core, but want to put out as part of last call. doesn't look like
we can do that. would hope to get them complete by august 3rd johnh: if eve can tidy it up, august 3rd id do-able rob: get normative spec. work done first. jeffh: no need to release all together paulm: exec overview draft next week rob: start in july, but prateek and i on holiday. need a
substitute chair hal: should definitely do the meeting with substitute chair jeffh: eve and/or i can do this. official business could be
done first, and then focus on technical issues rob: prateek and i will figure it out offline implementation guidelines ------------------------- charles: use ID-FF guidelines johnk: a lot of mobile specific guidance prateek: should add enterprise guidance, i'll be happy to
review hal: cumulative knowledge johnk: need to point to impl guidelines on website too, to
allow quick updates discussion of use of saml-dev list members or adding a wiki AI: Scott will investigate use of wiki on Oasis site rob: when can we get first draft? charles: end of july... migration doc (scott, prateek) ------------------------------ scott: very busy, won't get to it until late july, early
august prateek: also busy scott: will happen somewhat organically in liberty rob: (reviews schedule) we require attestations before
august 3rd prateek: "attestations" by some definition... rob: talk about attestation process hal: issue is granularity. doing every combination will not
fly. rob: we're not doing implementation yet hal: points out ability to waffle scott: don't need to cover the whole spec. we required 3
doing each piece of the spec. in 1.1 hal: definition is loose enough to lower the bar rob: but is anyone actually going to do this? jeffh: sun may attest, but depends on where we set the bar scott: should agree on an errata process. just want to be
able to fix the spec. don't know oasis rules. rob: no Oasis errata guidelines - may not modify spec. till
public review is done jeffh: but should not be known flaws in spec. when go public hal: oasis did not ack. AI: chairs to put item regarding errata process on the
concall agenda hal: recommends XACML errata process rob: (break?) prateek: should discuss attribute profiles GUIDs afterwards -- break
prateek: start with attribute profiles johnh: yes johnh: want to be able to transport PAC (or parts thereof)
in SAML attrib stmt. prateek: these are GUIDs, right? johnh: (explains DCE use of GUID, friendly name) prateek: we understand johnh: not seen the ability to do this in the specs. prateek: optional XML attrib for friendly name. we struggle
with the attrib value - is there one? johnh: repeats use-case prateek: all of that is captured in attrib designator scott: trying to understand what the value is johnh: value is GUID scott: profile is "backwards" hal: well-known uuid that represents Principal? prateek: summary - name is UUID, value is also UUID johnl: line 907 - dashes - is this a common way to represent
UUID as URI? prateek: we need a normative ref to UUID as URI syntax scott: uuid as uri sidesteps some of the punctuation issues rob: would that be acceptable (UUID as URI)? johnh: these are just nasty unreadable strings usage of UUIDs (discussion of what to reference) johnh: that would be acceptable AI: (Jeffh) Resolve status of RFC scott: more concerned about what it is we're trying to do
here. all attribs in PAC must have an value associated with the name.
(walks through his understanding of the profile) hal: it's little more complex. johnh: extended PAC is more complicated, but we really need
only a subset. You'll have only a single instance of a Principal.
we just want to carry the UUID+friendly name of Principal + Principal's
group info rob: can we do an example? scott: (draws it) can we define a friendly name attrib in
the SAML namespace? hal: call it DCE name instead of friendly name? scott: we already have a friendlyname attrib. so just use
that --- example --- <Attrib NameFormat="URI"
Name="urn:uuid:..." FriendlyName="Principal"> <attribValue
FriendlyName="(principal-name)"> urn:uuid:representing:dce_principal </attribValue> </Attrib> --- end example --- value itself conor: don't need to argue about element vs. attribute (discussion of multiple lists of values mostly between hal
and conor) rob: need to specify this in the profile - is name of profile
relevant to profile? scott: profile is addressing two things - primarily use of
UUIDs in attrib values. The secondary purpose might be to call out
the applicability of this to DCE use-case. No need to call out
that these attribs are part of a format. hal: should document the well-known formats for attribute
name. there's a short list AI: (Scott) to document the well-known values for the DCE
attribute name scott: silly to add sub-element to attribute value when we
already have a structur efor this (discussion of XML attribute values) rob: leave it to profile johnh: (signs off) (no answer) PKI Cross-domain profile (pki-cross-domain-profile-draft-01.doc) --------------------------------------- rick randall: (introduces himself) rickr: profile user is a large gov't agency interested in
SAML rickr: (explains use-case) rob: want to exchange attributes to allow authz rickr: subject name is carried, they want xml encryption +
signature hal: are they using public keys for subject confirmation? hal: info about subject could be obtained from cert. rob: in the PKI environment - there is one domain issuing
certs for its users. Other domain issues certs for its own users. There is
mutual auth between domains, but one domain doesn't know the other's
users scott: grid community has same use-case rickr: (explains profile) rickr: auth over client-auth SSL paulm: could be other type of cert-based auth hal: doing exact match on subjectname of cert. query will
require encryption prateek: is this the Shib use-case? scott: yes, not necessarily doing client-auth rob: and the grid... scott: main issue is use of temp ID during auth exchange.
there is a weak implicit presence proof. there is nothing that connects
the auth exchange betwene the client and domain b and the attrib
query at domain a. so, it's dependent on policy at domain a. johnl: decision at domain a has nothing to do with user
presence + confirmation hal: this is not the issue - some people only want to
release info when user is present. (gives example) rob: no tie between the auth exchange and the attribute
release scott: as long as authorities understand that there is no
ability to determine user presence.... rob: short-term identifiers cna be used to do this rob: customer is not concerned about another random site
doing queries? rickr: PKI trust is already established between domain a and
domain b prateek: SAML 2.0 can model these flows scott: we'd need to check the encryption requirements.
domain b can encrypt keys for domain a. scott: can sign the request, can pass the encrypted name
identifier, and we support attribute encryption (as well as encrypting the
entire assertion). steve: subject is encrypted for different party scott: encrypted thing is the subject of the query hal: need to re-encrypt scott: why? (symmetric key is encrypted with public key of domain a) hal: at minimum should use a different public key scott: why re-encrypt? steve: sender needs to keep a copy of the blob. (discussion of how to do this) hal: you have to correlate these things. profile could say
that you could just send the encrypted id back, or re-encrypt. rob: we say it must be the same subject going back scott: id must be identical rob: what does exact match, "identical" mean in
this case? We should clarify this scott: encryption should not affect this equivalence - don't
mean to preclude a name id being re-encrypted. hal: one way to disambiguate is to differentiate name id
from encrypted name id AI: (Scott) Will fix spec. to be more precise about use of
encryption with name identifiers. Steve: profiles should say something about this - for this
one, profile should state that either the name identifier will come back
with same encryption, could be multicast encrypted, or re-encrypted by
domain b. prateek: this use-case is covered prateek: what is the status of this profile? we can meet
your requirements? rickr: yes. they want to do a procurement, and want a
specification to point to. prateek: already done. FORMALLY: Rick (and customer) should read and accept the
OASIS IPR policy. rob: (explains IP policy) rickr: willing to accept now scott: reads text to meet previous AI rob: need to see it written down prateek: rick should send an email making a patent disclosure
to TC mailing list prateek: does this have to be a 2.0 work item? Alternative is to make a separate document to decouple from
current release schedule. mikem: two months ago, we closed for new work items different timeline jeffh: this raises the SAML versioning issue again (versioning discussion) paulm: if just a resource issue, then i would be happy to
help get this work done in saml 2.0 timeframe hal: goal is to have something official out of oasis as soon
as possible (discussion of the cut-off date) prateek: (summarizes) (group discussion of profile name) hal: if you give a general name, there will be pressure to
generalize the profile scott: should be fairly general prateek: is there an issue? hal: no well-formed profile yet prateek: what instruction are we giving? group: new ref of draft incorporating comments received
today scott: if goal is just product conformance, then conformance
would be at product level, and profile would be quite general. rickr: customer wants profile to be more stringent prateek: agrees that we should work this out within the TC,
rather than leaving it to RFPs etc. scott: seems like a missed opportunity if we write the
profile too narrowly rickr: (lays cards on table) would very much like to include
this profile in main profiles document, and explains reasoning hal: maybe we should reconsider the cut-off date, if we have
a full profile document conor: acceptance for what you want to do, it's just a
question of timing scott: look at SSO profile for example (and explains how to
reference other profiles) (group) profile can treate domain b auth server at domain b
destination web site as same entity for purposes of profile. (if you
don't want to use custom product for destination web site) rob: other questions? rickr: what happens after new version of profile? rob: (explains process) we'll discuss this on a call steve: any general disposition on profiles? AI: (chairs) discuss + resolve general approach to new
profiles rob: do rest of profiles document after lunch scott: want to leave with a good idea of what profiles need
to be in the document prateek: modify schedule to do profiles next, instead of
conformance rob: (modifies schedule, adjourn for lunch) -- lunch -- From: Charles Knouse [cknouse@oblix.com] PROFILES (Scott) Section 4.1.6 Use of Metadata Discussion of coupling of profiles with metadata. Prateek: How does metadata coupling show up in conformance? Scott: Intent not to require use of metadata to configure
implementation; but if using, then conform to normative rules for use. Section 4.1.4.3 "Security context SHOULD be discarded once
SessionNotOnOrAfter reached". Discussion of what security context is. "derived from
assertion", ACTION ITEM: Jeff to add security context to Glossary. Should be SHOULD or MUST? MUST in ID-FF. Leave as SHOULD;
explain implications in Implementation Guidelines. Scott: Profiles to be done 1. Single Logout 2. NameID Management 3. Authn Query 4. Attribute Query 5. Authz Query 6. Assertion Request 7. Artifact Resolution Only profile 3-7 for synchronous exchange (e.g. SOAP
binding) What is Authn Query for? Rob has seen use case. Should 1, 2 be pair of profiles for front channel and back
channel? optional vs. mandatory for conformance. Conclusion: single profile. Profiles that are done: Browser SSO, NameID mapping, ECP SSO Sections: Single Signon Profiles: Browser SSO. ECP SSO, Single
Logout Queries: Authn, Attribute, Authz NameID Management AssertionID Request Artifact Resolution ACTION ITEM: Jeff to help with sequence diagrams for
profiles. -----------------
Scott: Should change Response to AuthnResponse, since every
one keeps using that? no SAML Core message formats e.g. AuthnRequest Response Bindings: HTTP Redirect Form Post HTTP Artifact HTTP URI SOAP PAOS Messages over bindings, e.g. HTTP-Redirect(<AuthnRequest>) SOAP(<AttributeQuery>) Profiles, e.g. Browser SSO ECP Logout NameID Management Roles IdP SP Conformance statement: e.g. Product in role IdP implements Browser SSO profile consumes HTTP-Redirect(<AuthnRequest>) responds Form Post(<Response>) Scott: SOAP has additional interop requirements, e.g.
security, which metadata does not cover. How granular should conformance statements be? Too fine grain has negative impact for marketing. Precise product specification vs. mandatory to implement Need term from claims of support; want to use same language
for conformance statements Hierarchical approach: higher level for marketing, lower for
product specs General agreement that SSTC needs to define the language,
else someone will. Proposal for course grain conformance matrix
IdP
SP Web Browser SSO and logout Name ID mapping and management Mobile device Assertion query/request Scott: lumping queries together a mistake. Conor: good for implementers, doesn't solve deployers needs Prateek: conformance for vendors, not deployers Jeff: approach worthwhile, may disagree with individual
categories; Scott: Prateek: As ISV, sees Scott: Likes Conor: list of all possible knobs in SAML (!) Jeff: to make workable, not a lot of options in rows Scott: in Conor: battle in Scott: Displayed rows: features (e.g. SSO using Artifact Profile) columns: roles (IDP, SP Basic, SP, LECP) cells: MUST, OPTIONAL, blank Jeff: Prateek proposing unit of conformance is a cell, Scott: tool for combinatorial explosion of profiles x
messages x bindings Scott: no MUSTs in ACTION ITEM: Rob to enumerate the implementation
declarations/claims of interest. Prateek and Scott will contribute. Darren: agrees with new format and agrees need more granularity
than -----------------
SP uses PAOS; IdP uses SOAP Flow 1. EC -> SP: HTTP Request + PAOS header 2. SP -> EC: PAOS(<AuthnRequest>) + PAOS
header + ECP header 3. EC -> IdP: SOAP(<AuthnRequest>) 4. IdP-> EC: SOAP(<Response>) + ECP header 5. EC -> SP: PAOS(<Response>) 6. SP -> EC: HTTP Response Schema for ECP header goes into Core. -----------------
Subject Confirmation Scott: Assigned own subsection and type used for derivation
in subsequent sections. Also common attributes Scott: "Authenticating the subject" wrong? Jeff and Frederick: line 587 "specifies a subject"
should be "provides a means for a relying part to verify the correspondence
of the subject of the assertion with the party with whom they are
communicating." Scott: subsequent "authenticates" to be
"confirms". Scott: IPAddress attribute take the place of
<SubjectLocality> for products that need the user agent address (e.g. to
stick in a cookie). Should remove <SubjectLocality>? No resolution yet Discussion between Rob and Scott on whether in the Artifact
profile, does the browser present the assertion to the SP? Conor and Scott: In Artifact: browser presents assertion by
reference; In Post: browser presents assertion by value. KeyInfoConfirmationDataType Can hold multiple KeyInfos for multiple confirming entities.
Everything inside each KeyInfo must refer to the same key. Can be used for impersonation. AuthnMethod removed in favor of AuthnContext; AuthnContext
now required. SessionIndex moved from Statement to AuthnQuery. Cleaned up MUSTs for certain status codes. Cleaned up name IDs to support encrypted IDs. Removed authentication methods from Section 8. Changed language in Section 8.4.7 Persistent Identifier to
be less specific. Prateek to review. John Linn's issues (e-mail Monday June 7: comments on
sstc-saml-core-2.0-draft-14-diff.pdf) Assertion ID uniqueness OneTimeUse confusion: Hal: intended for attributes and authz decisions;
doesn't know how this applies to authentication John L: should tighten language to indicate this Scott: Bob M. suggested text missing on what
NotBefore/NotOnOrAfter means for attributes. ACTION ITEM: Hal will look at OneTimeUse text again and
attempt to clarify. DNSAddress vs. DNSName Security context needs to be in the Glossary. ACTION ITEM: John K. to clarity text on 909-911 on
SessionIndex. Steve: Why is SessionIndex required? John K: For logout. If you don't care, can always be 0. Conor: Does everyone support multiple simultaneous sessions? ACTION ITEM: John K. to look up why SessionIndex is
required. Discussion on what to do if signature verification fails?
Relying party SHOULD not rely on rely on assertion (!) Scott: Nothing in spec that requires second level status
codes. Can add codes that can be used. Implementations can have switch to report or suppress
secondary codes. Also can be logged. -----------------
Line 900: Artifact MessageHandle at least 16 (up from 8)
random bytes. Scott: Planned to steal 2 bytes from MessageHandle to hint
on AssertionConsumer metadata. Rob: If using SHA-1 hash for handle, need all 20 bytes. Scott to look at this again. Scott: security discussion in SOAP binding (sections
3.2.3.2, 3.2.3.3, 3.2.3.4) should be in conformance instead. Hal: Should be option to use WSS. Steve: Should call out several options MAY be used for
integrity and confidentiality. General confusion and amazement about section 3.2.3.1 on
HTTP headers and caching. Hal: Line 324 should declare the intention to not cache
response. Prateek: Preceding Sections 3.2.2.3-3.2.2.5
(protocol-independent SOAP) refer to sections 3.2.3.2-3.2.3.4 (SOAP over HTTP). ACTION ITEM: Scott to propose alternate text for section 3.2.3.1 strike 3.2.3.2-3.2.3.4. rewrite 3.2.2.3-3.2.2.5 Jeff: Some security choice needs to be mandatory to
implement, e.g. TLS. Section 3.4.5.1: similar issues to section 3.2.3.1. ACTION ITEM: Hal to get expert advice on how to prevent
caching by proxies and user agents. John Linn's issues Protecting association of RelayState with other SAML message
elements. Does ID-FF Security Considerations document issue? Need to say something in SSO profile and security
considerations about the issue. -----------------
Because of lack of quorum, recommendations will be made for
resolution at the next quorum call. CORE-7: SOAP Version in Protocol Binding RECOMMENDATION: CLOSE. Leave binding at v1.1 CORE-9: Wildcarding and Extensibility in the SAML Schemas Leave OPEN CORE-12: Consider Changing Name Identifier Format Default
for Issuer RECOMMENDATION: CLOSE. In prose, state the default is
"entity". CORE-16: Inconsistent Naming RECOMMENDATION: CLOSE. Make "Reference" to
"Ref" change. CORE-22:URIs vs.Prefixed QNames in Status Codes RECOMMENDATION: CLOSE. Scott to rework specs to use URIs as
appropriate. CORE-25: Require SessionIndex on LogoutRequest RECOMMENDATION: CLOSE. Scott to update prose to explain why
not required. CORE-27: Consider Limiting Datatype of Attribute Name Leave OPEN BIND-3: Establish a Mandatory Profile Leave OPEN. TECH-1: Identity/Service Provider Terminology and Domain
Model Leave OPEN. TECH-3: Impersonation Using SubjectConfirmation and KeyInfo RECOMMENDATION: CLOSE. Check with Ron if HolderOfKey issue
resolved. TECH-4: Glossary Additions: Artifact, Binding, Profile Leave OPEN until associated action item is done. TECH-5 Improve Federation Terminology Leave OPEN until associated action item is done TECH-6 Highlight Privacy Considerations Leave OPEN. TECH-7 Add/Correct Instance Examples Leave OPEN. - |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]