[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: PROPOSED TEXT: Issue Group 11: Authorization Use Case
I'd be really interested in a straw poll on issue 11-01. Anybody care to comment? I can really see the utility of this, though I can also see how it could really complicate the SAML spec given the SSO specs, especially for conformance. My biggest concern is that say a vendor implements use case #1, but not use case #2. Are they SAML compliant? What about the converse? These 2 use cases seem quite orthogonal to me. I had some early thoughts on "profiles" of SAML conformance, such that SAMLauthn was SSO and SAMLAuthz. Or like DOM levels. Authn is level 1 and Authz is Level 2. But I haven't really thought this through. One of the key determiners of success/failure of specs is the number of "optional" components/encodings. This has even caused tremendous problem in XML, which has only 2 levels of conformance - well-formed and valid. There are many different states between these though. Such as a well formed XML document with entities that has a DTD but the DTD hasn't been found so entity replacement hasn't occured. This is well-formed, but incorrect from the author's perspective. Internal subsets are another sore point. My point on this is that even something that has 2 cleanly separated levels of conformance has problems on conformance. I think I'm tossing between a "drop" or a "concur" position, that is if over 50% are in favour, my vote should be in favour. Distinct from an Abstain which is a "sit on the fence" position and might mean quorum isn't reached. Cheers, Dave > -----Original Message----- > From: Irving Reid [mailto:Irving.Reid@baltimore.com] > Sent: Thursday, March 22, 2001 9:00 AM > To: 'security-use@lists.oasis-open.org' > Subject: PROPOSED TEXT: Issue Group 11: Authorization Use Case > > > I've rewritten this, based on email from Prateek and discussion during > various conference calls. > > - irving - > > > ---------------------------------------------------------- > Issue Group 11: > > ISSUE:[UC-11-01:AuthzUseCase] Use Case 2 in Strawman 3 > (http://www.oasis-open.org/committees/security/docs/draft-sstc > -use-strawman- > 03.html) describes the use of SAML for the conversation > between a Policy > Enforcement Point (PEP) and a Policy Decision Point (PDP), in > which the PEP > sends a request describing a particular action (such as 'A > client presenting > the attached SAML data wishes to read > http://foo.bar/index.html'), and the > PDP replies with an Authorization Decision Assertion > instructing the PEP to > allow or deny that request. > > Proposed Resolutions: > > 1) Continue to include this use case. > > 2) Remove this use case. > > > ------------------------------------------------------------ > ISSUE:[UC-11-02:AuthzFirstContact] A second scenario for the > Authorization > use case combines first contact single-sign-on > (ISSUE:[UC-1-05:FirstContact]), authentication > (ISSUE:[UC-5-01:AuthCProtocol]) and authorization. > > Scenario 2.2: Authorization Service, First Contact with Authentication > > In this scenario, the client makes contact only with the > application; there > is not a separate authentication phase between the user and > the security > system. > > > ** WITHDRAWN ** > > I'd like to withdraw this proposed scenario and corresponding > issue. This > scenario is based on the assumption that what I have called 'Login' is > within the SAML scope. Since it is not, Scenario 2.2 becomes > identical to > Scenario 2.1. The initiating entity must perform a separate, > non-SAML login > to the security system. > > ------------------------------------------------------------------ > 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