OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

o        strike

o        rewrite

26.   Hal to get expert advice on how to prevent caching by proxies and user agents



New Issues:

  1. Deprecation/removal of XKMS authn context class
  2. Versioning in Profiles and Metadata
  3. How to represent support for attribute profiles in metadata
  4. Verify purpose of EncryptionMethod in KeyDescriptor in metadata
  5. SSO profile is different in how role division is split across request response
  6. SSODescriptorType shouldn't be a base
  7. Need new name for AttributeRequestingService


Existing Issues:

  1. Because of lack of quorum, recommendations will be made for resolution at the next quorum call.  Refer to the ISSUES list recommendations at the end of the raw minutes text.



                             Raw Notes



[Steve Anderson begins as minute-taker]


  1. Roll call
    1. Quorum NOT achieved
    2. Attendance of Voting Members - This includes those folks that dialed in for portions of the meeting:

·         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

    1. Membership Status Changes

·         Gavenraj Sodhi Computer Associates - Lost voting status after 6/15/2004 F2F

·         Emily Xu Sun - returned from LOA 6/14

  1. Accept minutes from previous meeting, 8 June 2004
    1. http://lists.oasis-open.org/archives/security-services/200406/msg00050.html
    2. http://lists.oasis-open.org/archives/security-services/200406/msg00054.html

·         Quorum not achieved

  1. Spec Review: Authn Context, Metadata, Profile



- 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 Liberty, we needed it

                        - 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 Liberty) basically

                - 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

                  verify it

                - called "PasswordProtectedTransport" (3819)

                - don't want to confuse this with "Kerberos"

                - Jeff: suggests "PasswordOverProtectedTransport", because

                  "PasswordProtectedTransport" is misleading

                - Frederick: the old schema required authnMethod in authnStatement

                - 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

            - Frederick: line 4539 has "WTLS", why?

                - 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

                        - Irving: could be relevant as revokation check

                        - 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


  1. Spec Review: Authn Context, Metadata, Profile (cont)


- 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

            - Irving: suggests Major/Minor, like in core, if semantics

              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

            - [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


                - 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 Toronto

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



  1. Spec Review: Authn Context, Metadata, Profile (cont)


Profiles Discussion




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



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.


Frederick raised the issue that SAML cares about case - can an attribute profile override that? Consensus is yes, we are covered.


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  


Frederick - do these guidelines belong in core? Rob, it belongs in profiles in that it constrains functionality.


Basic Profile


Jeff - why does xsi:type neeed to be present? To know whether its a datetime or string etc


Frederick - I had thought we had deprecated Attribute queries? Authorization and frozen.




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



  1. Outreach documents:


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,


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

frederick: are we doing weekly "official" meetings?

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


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


  1. Back to profiles discussion:


prateek: start with attribute profiles

irving: is anyone still dialled in?

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

irving: that's why we need a more "readable" form for SAML attribute

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">

  <attribValue FriendlyName="(principal-name)">





--- end example ---


irving: if the value has structure, structure should be represented in

value itself

conor: don't need to argue about element vs. attribute

irving: xml schema makes representing such things difficult

(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 PAC. Don't want to standardize on friendly name


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)

irving: anyone dialled in?

(no answer)


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....

irving: fine for this use-case, not so for other use-cases

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

scott: why?

(symmetric key is encrypted with public key of domain a)

hal: at minimum should use a different public key

irving: use a "bulk 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

irving: no need to make changes to core spec.

prateek: what is the status of this profile? we can meet your requirements?

irving: do you want this to be an OASIS SSTC standard profile?

rickr: yes. they want to do a procurement, and want a specification to

point to.

irving: need to comply with IPR policy

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?

irving: initial submission asks for it to be part of 2.0 spec. set.

Alternative is to make a separate document to decouple from current

release schedule.

mikem: two months ago, we closed for new work items

irving: agrees, leaves the alternative open - separate document on a

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)


irving: (re-iterates point of 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.

irving: spec. will have MAYs, but RFP will say MUST

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.

irving: perhaps have two sub-profiles?

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


prateek: modify schedule to do profiles next, instead of conformance

rob: (modifies schedule, adjourn for lunch)


-- lunch --


From: Charles Knouse [cknouse@oblix.com]
June 16, 2004 afternoon




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

  NameID Management

  AssertionID Request

  Artifact Resolution


ACTION ITEM: Jeff to help with sequence diagrams for profiles.




  1. CONFORMANCE (Prateek)


Scott: Should change Response to AuthnResponse, since every one keeps using that? no


SAML Core message formats e.g.




  HTTP Redirect

  Form Post

  HTTP Artifact




Messages over bindings, e.g.



Profiles, e.g.

  Browser SSO



  NameID Management





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.

Frederick: mobile device seems different than other functional categories

Conor: good for implementers, doesn't solve deployers needs

Prateek: conformance for vendors, not deployers

Irving: only half true; deployers need to worry about federation between vendors

Jeff: approach worthwhile, may disagree with individual categories; Liberty made all options mandatory

Scott: Liberty products interop in wide range of environments because they implement all options

Prateek: As ISV, sees Liberty conformance matrix as serious barrier to implementation

Scott: Likes Liberty definitions of IdP-Basic and IdP-Extended

Frederick: two levels: marketing, technical

Conor: list of all possible knobs in SAML (!)

Jeff: to make workable, not a lot of options in rows

Scott: in Liberty matrix, basic, extended along columns, not rows

Conor: battle in Liberty over which requirements get support; push to not separate functionality

Scott: Liberty conformance by column roles


Displayed Liberty profile matrix (liberty-idff-1.2-scr1.0):

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, Liberty unit of conformance is a column. From experience, conformance across rows useful.

Scott: tool for combinatorial explosion of profiles x messages x bindings

Scott: no MUSTs in Liberty for security requirements like signing vs. TLS.


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 Liberty.




  1. ECP PROFILE (Scott)


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.

Frederick confirms flow is correct.




  1. Spec Review: CORE draft-14 (Scott)


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

Frederick: Should change "IPAddress" to "Address" for other types of addresses.

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

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.




  1. Spec Review: BINDINGS draft-12 (Scott)


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,, 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 on HTTP headers and caching.

Hal: Line 324 should declare the intention to not cache response.


Prateek: Preceding Sections (protocol-independent SOAP) refer to sections (SOAP over HTTP).



   propose alternate text for section




Jeff: Some security choice needs to be mandatory to implement, e.g. TLS.


Section similar issues to section


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.




  1. Spec Review: ISSUES

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]