[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario Variati ons
David, if we exclude credentials from SAML we are going to be left with very little in the way of identifying subjects. What is the point of a name assertion if we do not have standard ways of calling out "names" within it: public keys, string tokens, X509 DNs, Certificates, and yes, even name and password (just another secret credential). How can we have an interesting notion of an Az service if there are no standard credentials? > > I believe this was voted out of scope for SAML version 1.0, I have no reason to believe we have agreed not to standardize credentials. It remains on the issue list (I believe with an 8Yes/ 3No vote) and remains very much part of our discussion. I still do not understand the objection to Steps 2-4. One server sends another trusted server some credentials together with a payload; the second server in some unspecificed fashion reads the credentials and generates a name assertion and property assertions which it attaches to the payload. Where is the authentication protocol? - prateek > -----Original Message----- > From: Orchard, David [mailto:dorchard@jamcracker.com] > Sent: Tuesday, February 27, 2001 6:07 PM > To: Ahmed, Zahid; Mishra, Prateek; Orchard, David; Darren Platt; > UseCaseList > Cc: Maryann Hondo; christopher ferris > Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario > Variati ons > > > My reasoning on why the exclusion of authentication > mechanisms applies to > steps 2-4 is that 2-4 will effectively become Authentication > methods. What > is the point of 1 site giving another site a credential if > it's not going to > do anything with it, such as accept/reject? If nothing will > be done with > the credential, then we can't even standardize on it - how would we > guarantee conformance if we can't reject?! And if the second > site is doing > accepts/rejects of the credential, then it is an > authentication mechanism, > right? > > So my position is that credential presentation to a 2nd site > is actually an > application level thing from the perspective of SAML because > we won't be > defining any kind of recourse if the credential isn't > accepted/in the proper > place/etc. Thus that part is out of scope as well. > > I totally believe the community needs a machine to machine > authentication > mechanism that works on top of protocols like SOAP, ebXML nee > SOAP. We have > had to invent our own way for doing authentication with our > asp partners, as > I'm sure you have as well. But to me that is either a different WG, a > different (and subsequent?) spec in our WG (my favored option > BTW), or a > subsquent version of the spec. > > I believe this was voted out of scope for SAML version 1.0, > but I believe it > should be in scope for a XPAS ( XML Protocol Authentication > Service, my just > invented name ) or some such. We will definitely be needing > modularity/profiling in our spec. My rough idea is that > there will be a > SAML Authn and a SAML Authz profile in SAML 1.0, with XPAS a > close 2nd spec. > You could easily see somebody implement a SOAP Service with > XPAS and SAML > AuthZ, and somebody else implement a web server with SAML Authn. > > Maybe these aren't the right breakups for functionality, but > we will have to > do something about profiles. There is no reason why we have > to publish only > 1 spec, though the number of specs/profiles should be minimal > for obvious > conformance/interoperability reasons. > > So you see, I agree with what you are trying to do, it's just > a matter of > trying to hit something fairly modest for version 1.0. > > Cheers, > Dave > > > > > -----Original Message----- > > From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com] > > Sent: Tuesday, February 27, 2001 2:32 PM > > To: Mishra, Prateek; Orchard, David; Darren Platt; UseCaseList > > Cc: Maryann Hondo; christopher ferris > > Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario > > Variati ons > > > > > > > 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 > > > > > > > ------------------------------------------------------------------ > > To unsubscribe from this elist send a message with the single word > > "unsubscribe" in the body to: > > security-use-request@lists.oasis-open.org > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC