RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario Variati ons

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

> There is a misunderstanding here. We have agreed to exclude
> Authentication methods NOT credential representation! I 
> dont see how including some credentials within an XML document
> and sending it to a server constitutes an authentication
> service. All you are doing is trusting the server with
> your credentials. 

Prateek,

That's what I originally thought (all this Use case is
discussing is the exploiting Credential specification in
a XML message).

To reconcile David and Evan's comments w.r.t. use of 
Credentials and B2B application authentication as discussed 
in Issue# 2-05, I see 2 options: 

1) Should we have a clarification statement, indicating that 
steps 2-4 in Issue# 2-05 are consistent with the definition
and scope of Credentials defined in SAML and that the
B2B/Credential-based authentication service model used is 
out of scope of the 2-05.

OR, 

2) Should we have clearly delinated sections to 2-05 w.r.t.
what is in-scope and what is out-of-scope, as David and 
Evan suggest?

I strongly prefer #1. 

David/Evan,
Please let me know if option#1 is acceptable, s.t. we 
preserve steps 2-4 in 2-05?

I want to get a revised version out to the use-case group 
later today in line with the current inputs.

thanks,
Zahid



> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Tuesday, February 27, 2001 2:06 PM
> To: Ahmed, Zahid; Orchard, David; Darren Platt; UseCaseList
> Cc: Maryann Hondo; christopher ferris
> Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario
> Variati ons
> 
> 
> Zahid,
> 
> There is a misunderstanding here. We have agreed to exclude
> Authentication methods NOT credential representation! I 
> dont see how including some credentials within an XML document
> and sending it to a server constitutes an authentication
> service. All you are doing is trusting the server with
> your credentials. In the case that the credentials are secret
> credentials, that may be a risky thing to do but I dont see
> how it is excluded from our scope.
> 
> - prateek
> 
> 
> > 
> > It is true that we have voted on 5-03 (a), (b), and (c), 
> and that the
> > proposed use case in 5-03 applies Credentials to exchange 
> > authentication 
> > data between 2 B2B applications. Since we have decided to 
> not support
> > such Credential applications in the scope of SAML and furthermore we
> > are going to explicitly state in the spec something to the effect: 
> > "Authentication methods or frameworks are outside the scope 
> > of [OSSML]",
> > I'm willing to revise steps 2-4 in UC2-05 such that it 
> > remains consistent 
> > with 5-03 conclusions.
> > 
> > However, I must point out that non-human operated applications 
> > (communicating over the internet) do need ability to specify and 
> > transmit authentication data above the transport protocols such as 
> > HTTP and SSL. HTTP was primarily designed for browser clients and 
> > SSL was also designed as an authentication mechanism for end-point 
> > socket client (e.g., browser) and servers (e.g., web 
> servers). Hence, 
> > there may be situations where some folks may exploit the simplicity
> > of SAML Credential specification for sending authentication data 
> > at the application protocol level for such 
> application-to-application 
> > connectivity scenario even if we spellout that authenticaiton 
> > mechanism 
> > is out-of-scope of SAML, which I agree that it should. [E.g., I
> > know that ebXML Security WG has discussed such potential apps in
> > the past w/o any conclusions yet...]
> > 
> > 
> > > What I suggest is that the scenarios you propose should have 
> > > some clearly delineated sections so that we could vote on 
> > portions.  
> > > Say steps 2-4 are out of scope, but (picking fictious groupings) 
> > > 5-8 and 9-11 could be put into scope.  If they are all 
> > bundled together, 
> > > then I'm faced with the choice of voting No( to ensure previously 
> > > No stands) or voting Yes (to ensure new steps are added), 
> > and I don't 
> > > know which way I should vote.
> > 
> > Yes, I'm willing to delineate UC2-05 in the above stated 
> > manner, possibly
> > using the latest session mgmnt use case as the example. Lets 
> > talk about 
> > this in our tele-conf tomorrow, if need be.
> > 
> > thanks,
> > Zahid
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Orchard, David [mailto:dorchard@jamcracker.com]
> > > Sent: Tuesday, February 27, 2001 12:21 PM
> > > To: Ahmed, Zahid; Darren Platt; UseCaseList
> > > Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario
> > > Variati ons
> > > 
> > > 
> > > There's options missing from each issue:
> > > x) Drop this issue/scenario/requirement
> > > y) Seek further clarification
> > > 
> > > I'm a little fuzzy about the overlap betweent these issues.  
> > > We had a clear
> > > indication (10-1 on UC-5-3) that the use case group does not 
> > > want credential
> > > exchange in scope, yet UC-2-05 (steps 2-4) explicitly brings 
> > > this up and
> > > proposes making it back into scope..  
> > > 
> > > What I suggest is that the scenarios you propose should have 
> > > some clearly
> > > delineated sections so that we could vote on portions.  Say 
> > > steps 2-4 are
> > > out of scope, but (picking fictious groupings) 5-8 and 9-11 
> > > could be put
> > > into scope.  If they are all bundled together, then I'm 
> > faced with the
> > > choice of voting No( to ensure previously No stands) or 
> > voting Yes (to
> > > ensure new steps are added), and I don't know which way I 
> > should vote.
> > > 
> > > On the session mgmt, I broke them up - the general notion 
> of session
> > > management - and specific step sets.  Some people wanted 
> > session with
> > > timeouts, some wanted session with logouts, some wanted 
> > > session with logouts
> > > and timeouts.  
> > > 
> > > Cheers,
> > > Dave
> > > 
> > > > -----Original Message-----
> > > > From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> > > > Sent: Monday, February 26, 2001 3:13 PM
> > > > To: Darren Platt; UseCaseList
> > > > Subject: Inputs to Strawman/Issue List - Group 2: B2B Scenario
> > > > Variations
> > > > 
> > > > 
> > > > Attached is the B2B Transaction Scenarios that I been re-written
> > > > in terms of Issue List format adopted in latest strawman/issue
> > > > list document.
> > > > 
> > > > 1) ISSUE:[UC-2-05:B2B Transaction via an e-marketplace or 
> > > trading hub]
> > > > 
> > > > 2) ISSUE:[UC-2-06: B2B Transaction using different 
> > messaging and   
> > > >    application protocols]
> > > > 
> > > > 3) ISSUE:[UC-2-07:  B2B Transaction over multiple 
> > e-marketplace or 
> > > >    trading hubs/portals]
> > > > 
> > > > 
> > > > Sorry for late feedback; please provide any comments.
> > > > 
> > > > I will definitely provide in the future some UML based 
> interaction
> > > > diagrams; however, all three issues have detailed use case steps
> > > > described and also possible resolution questions.
> > > > 
> > > > >This input will no doubt be very useful then, and I look 
> > forward to
> > > > >benefiting from your expertise in this area.  In the 
> > > > meantime we should
> > > > >start tracking these scenarios on the issue list.  You 
> > > suggested that
> > > > >you could provide more details - could we ask that you 
> > > please do so,
> > > > >perhaps providing interaction diagrams if possible, so that 
> > > > we can add
> > > > >them to the issue list for Strawman 3?>
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Darren Platt [mailto:dplatt@securant.com]
> > > > > Sent: Wednesday, February 21, 2001 6:59 PM
> > > > > To: UseCaseList
> > > > > Subject: Issue Groups and Champions
> > > > > 
> > > > > 
> > > > > Here are the current list of issue groups, and thier 
> champions:
> > > > > 
> > > > > Group 1: Single Sign-on Push and Pull Variations - Darren 
> > > > Platt, Evan
> > > > > Prodromou
> > > > > Group 2: B2B Scenario Variations - Prateek Mishra, Zahid Ahmed
> > > > > Group 3: Sessions - David Orchard
> > > > > Group 4: Security Services
> > > > > Group 5: AuthC Protocols - Prateek Mishra, Bob Blakley
> > > > > Group 6: Protocol Bindings
> > > > > Group 7: Enveloping vs. Enveloped
> > > > > Group 8: Intermediaries
> > > > > Group 9: Privacy
> > > > > Group 10: Framework
> > > > > Group 11: AuthZ Use Case - Irving Reid
> > > > > 
> > > > > Please let me know if I missed anybody.
> > > > > 
> > > > > 
> > > > > 
> > > > > Darren Platt
> > > > > Principal Technical Evangelist
> > > > > Securant Technologies
> > > > > 1 Embarcadero Center, Floor 5
> > > > > San Francisco, CA 94111
> > > > > tel - (415) 315-1529
> > > > > fax - (415) 315-1545
> > > > > http://www.securant.com/
> > > > > -----------------------------
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > ------------------------------------------------------------------
> > > > > To unsubscribe from this elist send a message with the 
> > single word
> > > > > "unsubscribe" in the body to: 
> > > > > security-use-request@lists.oasis-open.org
> > > > > 
> > > > 
> > > > 
> > > 
> > 
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: 
> > security-use-request@lists.oasis-open.org
> > 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-use-request@lists.oasis-open.org
>