> 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:]
> 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:]
> > > 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:]
> > > > 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:]
> > > > > 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:
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to:
> >
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
>
