[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Straw Man 2 - Authorization Service
Use case 2: Authorization Service describes using [OSSML] as the protocol between a policy enforcement point and a policy decision point. This is a use case we're interested in; as we see it, in order to support the other use cases within OSSML we would have 90% of a PEP-PDP protocol, so we might as well go the rest of the way within OSSML rather than create a separate protocol. My point, and I do have one, is that unlike most of the other use cases this one is expected to take place within the boundaries of a single organization (or, perhaps, between an organization and an authorization service provider). The sort of assertion we expect to see here is "Allow the person described by this name assertion to read the URL http://secrets.company.com/really-really-private/business-plan.html". Only the most foolish of PEPs would act on an assertion like this that came from anywhere other than its own trusted PDP. I suggest that we add some text to the use case to make this clear. Actually, now that I think of it, I have two points about this use case. I'd like to propose a variant in which a single OSSML request-response between the PEP and PDP can include more than one authorization request. This is most interesting if we decide to include an authentication service within OSSML. In this case, the PEP-PDP could include credentials that are expected to result in a name assertion, and an authorization request for access to a resource based on the result of the authentication. - irving -
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC