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: RE: [security-services] Thoughts wrt draft-sstc-saml-issues-statu s-01


Title: RE: [security-services] Thoughts wrt draft-sstc-saml-issues-status-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