RE: PROPOSED TEXT: Issue Group 11: Authorization Use Case

["Orchard, David" <dorchard@jamcracker.com>]

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
>