[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] Thoughts wrt draft-sstc-saml-issues-statu s-01
My responses in line. Notice I have agreed to the status=deferred suggestion, so a number of these comments do not represent any change from my recommendation.
> -----Original Message-----
> From: Jeff Hodges [mailto:jhodges@oblix.com]
> Sent: Friday, January 25, 2002 6:06 AM
> To: oasis sstc
> Subject: [security-services] Thoughts wrt
> draft-sstc-saml-issues-status-01
>
>
> Below's my personal take on saml-issues-status-01. I've
> listed only the issues
> where I have a different opinion on their status.
>
> my $.02.
>
> JeffH
>
>
> > Line#
> > -----
> > 1 OASIS SSTC Open Issues Status
> >
> >
> > 2
> >
> > 3 draft-sstc-saml-issues-status-01
> >
> > 4
> >
> > 5 January 21, 2002
> >
> > 6 Hal Lockhart
> >
> > 7
> .
> .
> .
>
>
> > 36 ISSUE:[UC-7-02:Enveloped]
> > 37 Core specification in XML Signature Profile states
> that SAML assertions and protocols must use
> > 38 enveloped signatures. Recommend this be closed
> with a resolution of deferred.
>
> status=CLOSED
> resolution=assns are "fit for being enveloped"
I agree. Does anyone think the spec should point this out? Recommend closing it in any event.
>
>
>
> >
> > 57 ISSUE:[UC-9-02:PrivacyStatement]
>
>
> status=DEFERRED
I disagree. This is not an issue about functionality. We were unable to come to choose among a number of similiarly worded statements. There has been no progress on this item since then. Why do you believe we will achieve consensus on this in the future? I would prefer a proposed statement we can agree on now or close this for good.
>
>
>
>
>
> > 75 Design Issues
> >
> > 76 Group 1: Naming Subjects
> >
> > 77 ISSUE:[DS-1-02: Anonymity Technique]
>
> status=DEFERRED
I agree.
>
>
>
> >
> > 87 ISSUE:[DS-1-06: MultipleSubjects]
>
> status=CLOSED
I agree.
>
> >
> > 91 ISSUE:[DS-1-07: MultpleSubjectConfirmations]
>
> status=CLOSED
I agree. However, note as mentioned last week. The description in the report is wrong. The issue is about multiple ComfirmationMethods. Gil are you happy?
>
> >
> > 95 ISSUE:[DS-1-08: HolderofKey]
>
> status=OPEN
I disagree, lets leave this open for the moment.
>
>
> >
> > 100 ISSUE:[DS-1-09: SenderVouches]
>
> status=OPEN
No change.
>
>
> > 109 ISSUE:[DS-3-02: ClockSkew]
>
> status=DEFERRED if someone willing to argue for future
> consideration, else
> status=CLOSED
I proposed this orginally and attracted no support, so I feel justified in recommending we close it. This stance also seems consistent with the general SAML philosophy "policy is a local matter and not subject to standardization."
>
>
> >
> > 112 ISSUE:[DS-3-03: ValidityDependsUpon]
>
> status=DEFERRED if someone willing to argue for future
> consideration, else
> status=CLOSED
I thought somebody, Prateek? wanted this deferred.
>
> >
> > 114 Group 4: Assertion Style
> > 115 ISSUE:[DS-4-02: XML Terminology]
> > 116 This is no longer subject to debate. Recommend closing it.
>
> champion=JeffH
>
> status=CLOSED
>
> write-up...
>
> wrt: DS-4-02: XML Terminology
> http://lists.oasis-open.org/archives/security-services/200109/
> msg00054.html
No change. Text accepted.
>
>
> >
> > 117 ISSUE:[DS-4-04: URIs for Assertion IDs]
>
> champion=JeffH
>
> status=CLOSED
>
> write-up...
>
> composition of AssertionID (Issue: DS-4-04: URIs for Assertion IDs)
> http://lists.oasis-open.org/archives/security-services/200106/
> msg00025.html
No change. Text accepted.
>
>
> >
> > 120 ISSUE:[DS-4-05: SingleSchema]
>
>
> status=CLOSED
No change.
>
>
> > 123 ISSUE:[DS-4-08: anyAtttribute]
> > 124 anyAttribute has not been added to the core
> schema. It is also not clear if there are additional
> > 125 issues relating to attribute schemas. This needs
> resolution.
> > 126 Champion: Eve Maler
>
> status=OPEN
No change.
>
>
>
>
>
> > 134 ISSUE:[DS-5-04: Request Reference]
> > 135 AssertionSpecifier has been dropped from Subject.
> Recommend closing it.
> >
>
> status=DEFERRED
I don't see why you think this will be added back in later. I thought we dropped it because it is just not needed. If we are going to need it in the future, why not just leave it in. Neither its syntax or semantics was in dispute.
>
>
>
> > 136 Group 6: Attributes
> > 137 ISSUE:[DS-6-01: Nested Attributes]
>
> status=DEFERRED
No change.
>
>
>
>
>
> > 144 ISSUE:[DS-6-05: AttributeScope]
>
> status=CLOSED
>
> "AttributeNamespace" satisfies this?
No change in resolution. However, Scott pointed out that "AttributeNamespace satisfies this"
is NOT correct. However, he does not seem to be arguing for a different resolution. I still think it should be closed for the reasons given in status-01.
>
>
>
>
>
> > 173 Group 9: Request Handling
> > 174 ISSUE:[DS-9-01: AssertionID Specified]
>
> status=OPEN
>
> processing model not yet clearly defined.
Ok, let's leave this open for the present.
>
>
>
>
> > 187 ISSUE:[DS-9-05: RequestAttributes]
> > 188 Current core does not include this element.
> Perhaps Target satisfied this requirement? This
> > 189 appears to be unresolved.
> > 190 Champion: Simon Godik
>
> status=DEFERRED
Simon are you satisfied to defer this? I thought it was a "must have" for Shib. Let's leave it open for the present.
>
>
> > ISSUE:[DS-9-06:Locate attributeAuthorities]
>
> in-process as of 22-Jan concall
>
> status=OPEN
This issue was missing from status-01, will apear in status-02.
>
>
>
>
>
>
>
> > 200 ISSUE:[DS-9-10: IssueInstant in Req&Response]
> > 201 Current core does not include this feature. This
> appears unresolved.
> > 202 Champion: Scott Cantor
>
>
> status=OPEN
No change.
>
>
>
>
> > 206 Group 11: Authorization Decision Assertions
> > 207 ISSUE:[DS-11-01: MultipleSubjectAssertions]
> > 208 Current core permits multiple subjects. I don't
> see any discussion of the semantics. This is
> > 209 unresolved.
>
>
> status=DEFERRED
I agree.
>
>
>
>
> >
> > 225 ISSUE:[DS-12-06: RequestALLAttrbs]
> > 226 Current core does not seem to specify any way to
> ask for all attributes. This is unresolved.
>
>
> status=DEFERRED
I disagree. There is a clear requirement for this functionality in SAML 1.0. The debate is whether to use a "keyword" or just specify no attributes. On the call it was stated that the intent was to specify no attributes, but the spec does not call it out. Anybody who wants a keyword, Eve? speak up now.
>
>
>
>
> > 242 ISSUE:[DS-14-07: BearerIndication]
> > 243 This functionality is provided in the Web Browser
> Post Profile, which specifies the use of a
> > 244 bearer SubjectConfirmationMethod, but this is not
> present in the core spec. This is unresolved.
>
> status=CLOSED
>
> addressed by SubjectConfirmation et al
I disagree. Bindings-09 line 174 says: The <saml:ConfirmationMethod> element of each assertion MUST be set to Assertion Bearer.
But core-25, section 7.1 does not list any such ConfirmationMethod.
>
>
>
>
>
>
> > 252 ISSUE:[DS-14-11: CompareElements]
> > 253 Current core is silent on how these element are to
> be compared. This would seem to imply only
> > 254 exact binary matching. Recommend this be closed.
>
>
> status=OPEN
>
> I echo Steve Farrell's concerns about this -- we likely need
> to think more
> carefully about this.
I agree this may be a problem, but there have been no concrete proposals on this in the last six month, so if we are going to last call, somebody better come up with something quickly instead of just saying it is broken.
>
>
> ---
> end
Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC