RE: Updated Issues List (draft-sstc-saml-issues-06.doc)

["Mishra, Prateek" <pmishra@netegrity.com>]

I am a little puzzled why this is an "issue". After all there
is no change to schema or scope or anything at all. Each
technique needs to be given a brief description and a reference
link. Am I missing something here?

My thinking
would be that we should "collect" a list of standard techniques
and ensure that they are entered into core-16. 

BTW, the current SOAP Profile utilizes (1) XML-DSIG (2) hash
utilizing XML-DSIG elements, as two distinct subject authentication
techniques. I would like to see these techniques added to this
list.

In terms of the f2f, would it make sense to call for techniques
that are of interest to people and to have a "champion" collect
and publish them?  

- prateek

>>-----Original Message-----
>>From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
>>Sent: Thursday, August 23, 2001 5:14 PM
>>To: 'Daniel Ash'; 'Tim Moses'; 'OASIS Security Services group'
>>Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc)
>>
>>
>>I think what we are all talking about is some machinery in 
>>the core schema
>>that can be used as needed by different bindings. 
>>
>>The question is whether to open a new issue or simply add 
>>some text to the
>>current one. I don't want to have a lot of open issues on the 
>>same subject,
>>but I also don't want to "lose" the issue by inappropriately 
>>combining it
>>with a different one.
>>
>>I think we need an XMLdsig profile as well, but we need to 
>>specify some use
>>of SubjectConfirmation that enables this in the SAML schema.
>>
>>Hal
>>
>>> -----Original Message-----
>>> From: Daniel Ash [mailto:Daniel.Ash@identrus.com]
>>> Sent: Thursday, August 23, 2001 4:24 PM
>>> To: 'Tim Moses'; 'OASIS Security Services group'
>>> Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc)
>>> 
>>> 
>>> I agree that a SOAP and/or SMIME profile should indicate the 
>>> use of signatures for subject authentication, however, what 
>>> about other bindings?  I actually favor the approach where an 
>>> XMLSIG profile of XML-Protocol indicate this functionality 
>>> (as part of XML-P) so that any application and/or protocol 
>>> bound to XML-P doesn't have to worry about it.  Though, in 
>>> the short term, if many implementors plan to bind directly to 
>>> HTTP then it might make sense to go with Tim's original suggestion.
>>>  
>>> -dan      
>>> -----Original Message-----
>>> From: Tim Moses [mailto:tim.moses@entrust.com]
>>> Sent: Thursday, August 23, 2001 3:49 PM
>>> To: 'OASIS Security Services group'
>>> Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc)
>>> 
>>> 
>>> Hal - Perhaps you are right.  I originally thought this was a 
>>> different issue (one solved by allowing the Subject element 
>>> to he a digest of a "document", so that the assertion could 
>>> be "about" the data, rather than about a person).  But, on 
>>> rereading, the mention of SOAP and S/MIME seems to suggest a 
>>> "store-and-Forward" communications model, with origin 
>>> authentication based on the signer's signature over the data.
>>> Can we conclude that Phill has the mandate to include the 
>>> text proposed in my contribution ... 
>>> http://lists.oasis-open.org/archives/security-services/200108/
>>> msg00041.html 
>>> Or can we only append the text from the contribution to the 
>>> description of the issue? 
>>> Best regards.  Tim. 
>>> 
>>> 
>>> -----Original Message----- 
>>> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] 
>>> Sent: Thursday, August 23, 2001 3:06 PM 
>>> To: 'Tim Moses'; 'OASIS Security Services group' 
>>> Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc) 
>>> 
>>> 
>>> Sorry to change my story, but I just noticed: 
>>> ISSUE:[DS-10-01: AttachPayload] 
>>> There is a requirement for assertions to support some 
>>> structure to support 
>>> their "secure attachment" to payloads. This is a blocking 
>>> factor to creating 
>>> a SOAP profile or a MIME profile. If needed, the bindings 
>>> group can make a 
>>> design proposal in this space but we would like input from 
>>> the broader 
>>> group. 
>>> Status: Open 
>>> Is this the same issue? Can we just add some text to it to 
>>> include your 
>>> proposal? 
>>> Hal 
>>> > -----Original Message----- 
>>> > From: Tim Moses [mailto:tim.moses@entrust.com] 
>>> > Sent: Thursday, August 23, 2001 2:09 PM 
>>> > To: 'OASIS Security Services group' 
>>> > Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc) 
>>> > 
>>> > 
>>> > Hal - The only written response to my contribution on this 
>>> > topic was from Dan Ash (and that was supportive).  I did 
>>> > speak with Phill about it, and (I think) he felt he needed 
>>> > the group's explicit instruction to include it.  I have 
>>> > suggested text on the topic for the SubjectConfirmation 
>>> > section, but that text was not included in Core 15.  I am 
>>> > trying to figure out how best to get the "group" to instruct 
>>> > Phill to include it in the next draft.  Best regards.  Tim. 
>>> > -----Original Message----- 
>>> > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] 
>>> > Sent: Thursday, August 23, 2001 2:02 PM 
>>> > To: 'Tim Moses'; 'OASIS Security Services group' 
>>> > Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc) 
>>> > 
>>> > 
>>> > Sorry, I just missed it. I will add it. 
>>> >  
>>> > After doing a little research I am confused. At first I 
>>> > thought, we have a usecase for some kind of document exchange 
>>> > in a store and forward environment that would mandate this. I 
>>> > can't find one in draft-sstc-saml-reqs-01. The only thing I 
>>> > found is a requirement for an ebXML binding, which I suspect 
>>> > will require this, although I am not that familiar with 
>>> > ebXML. I also cannot find open of closed issues on this kind 
>>> > of a use case. Can anyone help me out? Does anyone from the 
>>> > usecase group remember if store and forward transactions are 
>>> > supposed to be in or out? 
>>> >  
>>> > Assume the answer is "in", is this issue controversial? 
>>> > Personally I thought this was one of the intended uses of 
>>> > SubjectConfirmation. (I am having trouble following the 
>>> > discussion thread, because this was originaly one point among 
>>> > many in your comments.) Have there been any arguments against it? 
>>> >  
>>> > Hal 
>>> > -----Original Message----- 
>>> > From: Tim Moses [mailto:tim.moses@entrust.com] 
>>> > Sent: Wednesday, August 22, 2001 4:21 PM 
>>> > To: 'OASIS Security Services group' 
>>> > Subject: RE: Updated Issues List (draft-sstc-saml-issues-06.doc) 
>>> > 
>>> > 
>>> > Hal - I do have one issue that I would like to raise.  I 
>>> > could offer to "champion" it, if it is appropriate. 
>>> > There is a need for a subject confirmation method based on a 
>>> > signature over a document.  Carlisle has dubbed this 
>>> > "unaccompanied data".  Also, see Dan Ash's posting on the 
>>topic ... 
>>> > http://lists.oasis-open.org/archives/security-services/200108/ 
>>> msg00029.html 
>>> Should this method be added to section 4 of Core 15? 
>>> All the best.  Tim. 
>>> -----Original Message----- 
>>> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] 
>>> Sent: Wednesday, August 22, 2001 10:51 AM 
>>> To: 'security-services@lists.oasis-open.org'; 
>>> 'security-editors@lists.oasis-open.org' 
>>> Subject: Updated Issues List (draft-sstc-saml-issues-06.doc) 
>>> 
>>> 
>>> The issues list has been updated to reflect recent 
>>> discussions on the list. 
>>> Some arbitrary decisions were made about what are issues and 
>>> what are merely 
>>> editorial comments. Please let me know if I have missed your issue. 
>>> The issue status report has been delayed but will be issued soon. 
>>> Hal 
>>> 
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>