[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
· 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 22.214.171.124
o strike 126.96.36.199-188.8.131.52.
o rewrite 184.108.40.206-220.127.116.11
26. Hal to get expert advice on how to prevent caching by proxies and user agents
[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
- 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
- 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
- Scott: this is not any formal use of XML Schema that you would
- 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
- 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
- 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
- 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
- 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)
- 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
- AdditionalMetadataLocation allows implementations that support
both ID-FF and SAML 2 metadata to publish both forms, cross-
- really, is a form of versioning
- [ISSUE] How to represent support for attribute profiles in
- 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
- 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
- SSODescriptorType (line 536)
- Scott: "ArtifactLookupService" doesn't sound right
- "ArtifactResolverService"? "...Dereference..."?
- needs to be consistent with related protocol components
- winner: ArtifactResolverService / ArtifactResolve /
- [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
- [OLD ISSUE] some wanted to add location hinting to artifact, to
support multiple artifact resolvers
- ArtifactResolverService will resemble AssertionConsumerService,
- Artifact format will include space for this Index
- [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
- 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
- Scott: dislikes "Service" in "AttributeRequestingService"
- [ISSUE] Need new name for AttributeRequestingService
[Paul Madsen taking over minute-taking]
June 15, 2:45 - 5:00, Minutes
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
-Connecting to Metadata
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
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
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
Jeff - why does xsi:type neeed to be present? To know whether its a datetime or string etc
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.
Intent is that UUIDs occur as attribute names. Not so clear whether there are values.
[ACTION] - Prateek to ping John for clarification.
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 [firstname.lastname@example.org]
Minutes 2004-06-16 (morning) SSTC F2F
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,
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
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
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
prateek: should discuss attribute profiles GUIDs afterwards
prateek: start with attribute profiles
johnh: want to be able to transport PAC (or parts thereof) in SAML
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
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">
--- end example ---
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
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
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)
PKI Cross-domain profile
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 +
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
steve: subject is encrypted for different party
scott: encrypted thing is the subject of the query
hal: need to re-encrypt
(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
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
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
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
prateek: does this have to be a 2.0 work item?
Alternative is to make a separate document to decouple from current
mikem: two months ago, we closed for new work items
jeffh: this raises the SAML versioning issue again
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)
(group discussion of profile name)
hal: if you give a general name, there will be pressure to generalize
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
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
(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
prateek: modify schedule to do profiles next, instead of conformance
rob: (modifies schedule, adjourn for lunch)
-- lunch --
From: Charles Knouse [email@example.com]
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.
"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
Single Signon Profiles: Browser SSO. ECP SSO, Single Logout
Queries: Authn, Attribute, Authz
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.
Messages over bindings, e.g.
Conformance statement: e.g.
Product in role IdP implements Browser SSO profile
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
Web Browser SSO and logout
Name ID mapping and management
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
Prateek: As ISV, sees
Conor: list of all possible knobs in SAML (!)
Jeff: to make workable, not a lot of options in rows
Conor: battle in
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
SP uses PAOS; IdP uses SOAP
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.
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.
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
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 18.104.22.168, 22.214.171.124, 126.96.36.199) 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 188.8.131.52 on HTTP headers and caching.
Hal: Line 324 should declare the intention to not cache response.
Prateek: Preceding Sections 184.108.40.206-220.127.116.11 (protocol-independent SOAP) refer to sections 18.104.22.168-22.214.171.124 (SOAP over HTTP).
ACTION ITEM: Scott to
propose alternate text for section 126.96.36.199
Jeff: Some security choice needs to be mandatory to implement, e.g. TLS.
Section 188.8.131.52: similar issues to section 184.108.40.206.
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
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
BIND-3: Establish a Mandatory Profile
TECH-1: Identity/Service Provider Terminology and Domain Model
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
TECH-7 Add/Correct Instance Examples