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] | [Elist Home]

Subject: [security-services] Minutes for Focus Group Telecon Tue 2-Apr-2002

Joe: intend to discuss ds-1-10

prateek: any word from RSA about license intent?

rob: we're meeting later today, can you (chairs) send comments?

Joe: mentioned karl's note, need to request clarification from Karl about the
intent of the new approach. 

[Action 1] joe/Jeff to solicit clear IPR procedure statement from Karl

ds-1-10  discussion

[ds-1-13 is closely related]

applicable messages..

New Issue: SubjectConfirmation descriptions 

ISSUE: core-27: Should AuthenticationMethods andConfirmationMethods be listed
in the same subsection? 

hal: will settle for addressing this with a warning that no matter what the
ConfirmationMethod says, it's the profile that needs to describe precise use of
SubjectConfirmationData material. 

e.g. to use a kerberos ConfirmationMethod & SubjectConfirmationData, one needs
to specify whether the included ticket is a TGT or a service ticket and other
stuff. in contrast, AuthenticationMethod is relatively easy to include in
assertions and base subsequent policy on. 

prateek: suggests we retain list as AuthenticationMethods, prune as
appropriate, then define ConfirmationMethods in the bindings spec as

[further discussion around Prateek's proposal, culminating in...]

Agreed-to resolution to DS-1-10, DS-1-13:

re-label core-29 section 7.1 as "Authentication Methods"
 include some appropriate note in subsequent version of core-xx to the effect..

  "ConfirmationMethod identifiers and their semantics/use are defined in
   SAML bindings & profiles. Some are presently defined in [SAMLBind]."

 need to drop a few AuthenticationMethods, clarify the prose describing 
 the rest.

Presently defined & employed ConfirmationMethods (and attendant
SubjectConfirmationData values) will be defined in appropriate places in the
subsequent version of bindings-model-xx, and it'll also have a (sub)section
summarizing the presently defined & employed ConfirmationMethods...
 sender vouches

wrt the OASIS-specific URIs identifying AuthenticationMethods &
 use "am" in AuthenticationMethods listed in core
  e.g. urn:oasis:names:tc:SAML:1.0:am:password

 use "cm" in ConfirmationMethods listed in bindings
  e.g. urn:oasis:names:tc:SAML:1.0:cm:Holder-Of-Key

[Action 2] Hal will make a proposal for the changes to core-29 section 7.1, as
described above. Will try to make the proposal by COB today.

[Action 3] Prateek to make appropriate changes to bindings-model-13 and issue
new spec by Thur 4-Apr. 

[Action 4] Phill to incorp Hal's suggested changes to core-29 within 24hrs of
Hal's proposal. 

Editorial fixes to various docs

[Action 5] Phill, Prateek, perhaps others..

Assuming the editors agree and the suggestions aren't found controversial by
others, then these suggestions (and others submitted by today) should be

Comments on bindings-13

RE: [security-services] Comments on bindings-13 

minor editorial comments on core-29 

NOTE: there's further action, [Action 6], identified near the end of this msg

have we closed all open issues?

Review of red-coded open issues in issues-status-05

we just worked on DS-1-11 & DS-1-13 (see above), so will skip them for now. 

Note: all "done"s below means the item was addressed in core-29 or
bindings-model-13, as appropriate.

DS-1-11 & DS-1-12 

  done  (see discussion at end of these minutes wrt to schemalocation)


  Was deferred during 19-Mar-2002 telecon

  Minutes for Telecon, Tuesday 19 Mar 2002

  was closed during 19-Mar-2002 telecon




  done  line 426


  not done in core  -- but will be addressed as a part of DS-1-10 resolution
  done in bindings


Prateek noted that at least one item agreed to during the 26-Mar-2002 (last
week's) concall wasn't incorp'd in core-29.

Review of 26-Mar-2002 minutes 

Note: all "done"s below means the item was addressed in core-29 or
bindings-model-13, as appropriate.

> [RLBob] InResponseTo optional
>         proposed text change to core-28 to list - included in spec (Phill?)
> http://lists.oasis-open.org/archives/security-services/200203/msg00127.html
> [Minutes] Change accepted. Editor to add to Core-29.

done  line 1142

> [Hal] New Issue: Should Queries contain a full Subject?
> http://lists.oasis-open.org/archives/security-services/200203/msg00129.html
> Resolution: We will include text to characterize the general threat described
> under part 3 of Hal's message. An additional error sub-status code "Request
> Denied" and the conditions under which it is to be used described. No change
> to schema for subject in query.
> Prateek will write this text and Rob P. will review. This text will be added
> to the core document. Motion passes.

done  line 1040

> [Hal] [security-services] New (minor) Issue: AuthNMethod, not
> ConfirmationMethod in AuthNQu ery
> http://lists.oasis-open.org/archives/security-services/200203/msg00142.html -
> prateek's proposed changes
> [Minutes] Friendly amendment from Rob --- instruction to the editor -- text
> beginning at "first,... and
> further, etc..." should be split up into bullets so the processing steps are
> obvious.
> Motion passes.

done  line 1046

> [Hal] Text for "All Assertions"
> http://lists.oasis-open.org/archives/security-services/200203/msg00138.html -
> agreed? applied?
> lines 1317 & 1318 change the sentence to read:
> If no attributes are specified, it indicates that all attributes allowed by
> policy are requested.
> [Minutes]
> Motion passes.


> [Scott] Core changes for ISSUE DS-14-19
> http://lists.oasis-open.org/archives/security-services/200203/msg00143.html -
> [Minutes] Proposed and accepted.


> [Emily] Minor error in core 28
> http://lists.oasis-open.org/archives/security-services/200203/msg00145.html
> [Minutes] Proposed and accepted.

done line 1177

> [Scott] Core changes for ISSUE DS-4-13
> http://lists.oasis-open.org/archives/security-services/200203/msg00146.html -
> [Minutes]
> Joe: action to Scott.
> Scott will write text to rule out use of empty strings, rule out empty URIs
> other than for resources.

done  line 169, 753, 1080

> [Scott] Approved changes/cleanup for Status/StatusCode/etc.
> http://lists.oasis-open.org/archives/security-services/200203/msg00148.html
> Joe: move to accept change. Change is accepted and forwarded to Editor.

scott/prateek: done. line 1219 et al.

> [Hal] Base64 in core and bindings
> http://lists.oasis-open.org/archives/security-services/200203/msg00152.html
> Prateek: Is this an  instruction only for binding?
> Scott, Rob: what about subject confirmation data element? This is currently a
> string and cannot
> carry an arbitrary blob.
> Rob: Also occurs in Section 7.1
> Joe: any other changes for core other than making sure the spelling is
> correct?
> Joe: change is accepted. Editors to fix.

prateek: done in bindings

core: line 1559    done

> [Rob P] Comments on core-28
> http://lists.oasis-open.org/archives/security-services/200203/msg00161.html -
> editorial, applied?
> amendments:
> 4) change line 352 to start: "currently being defined"
> 6) replace application by terms a SAML requestor, SAML responder, where
> appropriate
> http://lists.oasis-open.org/archives/security-services/200203/msg00163.html -
> editorial
> [accepted]

done  rob verified them

minor correction  on lines 1334 & 1335 
  "authority" in all lines, shouldn't be, rob to send editorial comment to list

Phil to address. This is part of [Action 5], above. 

> [Rob P] Issue/editorial comment: Description of<Condition> processing in
> core-28
> http://lists.oasis-open.org/archives/security-services/200203/msg00162.html -
> agreed? applied?
> [accepted]

done  section  417 et al

> -------------------------------------------------
> (1)
> Scott: msg00146 - should the empty string restriction be generalized to
> whitespace in the text? Rob moves.
> Prateek seconds.

this actually passed, assesrted by prateek,  no obj. 

done line 173

> (2)
> Prateek: Motion is to change the type of SubjectConfirmationData to
> base64binary?
> Scott: Remove ds:KeyInfo and change SubjectConformationData to be anytype?
> Phil: objects to removal of ds:KeyInfo
> Scott: why not choose between the two?
> Phil: objects to exclusive choose
> Joe: Proposal to change of SubjectConfirmationData to AnyType.
> Motion passes.

not done. anytype is correct type for SubjectConfirmationData. 

Phil missed in core-29

[Action 6] Phill to address 

> (3) RL Bob's URN message to be applied to core and bindings.
> http://lists.oasis-open.org/archives/security-services/200201/msg00225.html
> Scott, Joe: explain that these URNs are available.
> Joe: Phil + Prateek to apply changes.


phill: one thing not done is the assertion schema location in the protocol
schema. will have to do that when we post to the website. 

scott: perhaps don't need to point schemalocation to exact location, but
perhaps can do relative schemalocation & the namespace. 

It's one thing to point authoritatively at, say, the dsig schema, but another
to have our protocol schema reference our assertion schema 

we should treat schema location as only a "hint" -- it can't be normative. 


In anycase, we'll ensure there's something reasonable in the protocol schema
for the assertion schema location at final publication time. 



Allen	Rogers	Authentica
Krishna Sankar 	Cisco
Gil	Pilz	E2open
Hal 	Lockhart	Entegrity
Joe  	Pato	HP
Jason 	Rouault 	HP
Marc	Chanliau 	Netegrity
Chris	McLaren	Netegrity
Rob	Philpott	RSA Security
Jahan	Moreh	Sigaba
Jeff 	Hodges 	Sun
Emily	Xu	Sun
Bob 	Morgan 	UWashington
Phillip 	Hallam-Baker 	Verisign

[did Irving arrive late? thought I heard his voice]


Scott	Cantor	OSU
Thomas 	Hardjono 	Verisign
Tim 	Moses 	Entrust


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC