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: Re: [security-services] Agenda for SSTC Conference Call, May 11


Status of my action items:

Mishra, Prateek wrote:
> *#0161*: Remove KeyInfo from Assertion top-level
> *Owner*: Eve Maler
> *Status*: Open
> *Assigned*: 30 Apr 2004
> *Due*: ---
> 
> *Comments*:
> Prateek Mishra 2004-04-30 18:16 GMT
> o Mike - what is difference in meaning for KeyInfo at top versus KeyInfo 
> inside SubjectConfirmationData
> 
> o Eve - no, just a syntactic
> 
> o discussion ensues, decision to remove KeyInfo
> 
> o Prateek - eliminating holder of key, Ron will have comments
> 
> o Decision - remove KeyInfo, allow within SubjectConfirmationData
> 
> *** AI - Eve to implement decision on core 18 after checking with Ron

This was done in core-10.  You can see it on lines 598-600 and 611 here:

http://www.oasis-open.org/committees/download.php/6347/sstc-saml-core-2.0-draft-10-diff.pdf

> *#0144*: Explain optional subject decision
> *Owner*: Eve Maler
> *Status*: Open
> *Assigned*: 29 Apr 2004
> *Due*: ---
> 
> *Comments*:
> Prateek Mishra 2004-04-29 21:51 GMT
> *** AI: Eve: Optional subject implemented in core spec prose. Schema 
> shows that subject is optional.
> 
> o Eve: Has wanted to create a rationale for some of the decisions made 
> on spec. Decision on subject less statements is a good example of what 
> needs to be documented. Making an explicit design decision that is not 
> really explicit on. By choosing to add prose to core spec we're making a 
> stealth abstract profile (generic design decision) that applies to all 
> explicit profiles.
> 
> o Scott: data model (design) decision to require subjects in all SAML 
> statements.

This is still open.  (In fact, I'd clean forgotten about it. :-)

> *#0143*: Check SAML schema for consistency
> 
> *Owner*: Eve Maler
> 
> *Status*: Open
> 
> *Assigned*: 29 Apr 2004
> 
> *Due*: ---
> 
> *Comments*:
> Prateek Mishra 2004-04-29 21:49 GMT
> *** Follow-up: Examine SAML schema for consistent use of XML attributes 
> vs. elements

Still open.

> *#0141*: Review/fix boilerplace text for Artifact Protocol
> *Owner*: Eve Maler
> *Status*: Open
> *Assigned*: 27 Apr 2004
> *Due*: ---
> 
> *Comments*:
> Prateek Mishra 2004-04-27 15:24 GMT
> o Prateek: Should we sign or authenticate?
> 
> o Scott: Common language on all protocol messages.
> 
> o Prateek: Concerned about text on line 2118 "...SHOULD be signed or 
> otherwise authenticated...."
> 
> o Scott: Not a MUST, need to provide some recommendation to protect 
> message.
> 
> o Eve: this is boiler plate text for all messages. Need to agree on the 
> correct text for this.
> 
> ***Follow-up: Review/fix boilerplate text re: recommendation for 
> protecting messages

Still open.  Will try to do this today.

> *#0140*: Update extensions element to use ##other
> *Owner*: Eve Maler
> *Status*: Open
> *Assigned*: 27 Apr 2004
> 
> *Due*: ---
> 
> *Comments*:
> Prateek Mishra 2004-04-27 15:22 GMT
> Scott - added Extensions element - modeled to be consistent with SOAP 
> header element - i.e. multiple extensions within one Extensions (header) 
> element.
> o Discussion of ##any vs. ##other.
> 
> o Should use ##other.
> 
> o Scott - should we have a wrapper element for extensions?
> 
> *** Follow-up: Resolution: change Extension to use ##other

This was done on line 1191 of core-09:

http://www.oasis-open.org/committees/download.php/6323/sstc-saml-core-2.0-draft-09-diff.pdf

> *#0135*: Why does signature need to be the first element?
> 
> *Owner*: Eve Maler
> 
> *Status*: Open
> 
> *Assigned*: 27 Apr 2004
> 
> *Due*: ---
> 
> *Comments*:
> Prateek Mishra 2004-04-27 15:00 GMT
> - Eve to ask Bhavna to post motivation for moving Signature to
> front

Bhavna has since sent a message that she was unable to find a suitable 
rationale, and was happy to leave the position as it is now, as long as 
it's in a *predictable* location:

http://lists.oasis-open.org/archives/security-services/200404/msg00113.html

I suggest that we just close this one.

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com



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