OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Requirement for Isolated Request for Authorization Atributes


I agree that ability to serve 'authorization attributes' should be covered
by our specification.  On ISSUE:[UC-1-08:AuthZAttrs], we unanimously voted
to "Edit the use case scenarios to specify passing authz attributes with
authentication documents."  That covers passing them for the SSO use cases.
Perhaps we can add a scenario in the "Security Services" issue group where a
'service' is queried for authroziation attributes related to a principal.
That way we can vote it in (or not) as we decide the scope of the service.
Hal has pointed out that this is a component of the ebXML use case as well,
but should probably be pulled out and decided on its own merits.

I'm afraid there may be some confusion around the terms we are using here,
though.  Philip seems to have agreed for the need for 'authorization
attributes', but then extended the concept to include 'autorization
assertions'.  In our work in the requirements group, we've found it useful
to seperate the concepts:
	Authorization Attributes - Attributes about a principal which may be useful
in an authorization decision (group, role, title, contract code,...).
	Authorization Assertions - (As described) The result of a authorization
policy decision.  In ISSUE:[UC-1-09:AuthZDecisions], we voted to add the
requirement: [CR-1-09-AuthZDecision] SAML should define a data format for
recording authorization decisions.

Regards,

Darren



> -----Original Message-----
> From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Monday, March 12, 2001 10:14 AM
> To: 'Hal Lockhart'; 'security-use@lists.oasis-open.org';
> 'security-core@lists.oasis-open.org'
> Subject: RE: Requirement for Isolated Request for Authorization
> Atributes
>
>
>
> I think this case will turn up frequently in the Web server delegated
> Authorization case.
>
> I don't think that we should enforce the idea that the issuer of
> authorization assertions has to be in any way required to be involved in
> authentication.
>
> If public key cryptography is used as the basis for authentication the
> concept of 'login' is irrelevant. Each party performs strong
> authentication
> with each other party it contacts on a per transaction basis. A
> key exchange
> to establish a shared secret may be employed as an optimization, but this
> does not consitute a 'login' per se.
>
> Another case in which the requirement would occur is in offline batch
> processing. For example, in an auction the participants all submit their
> bids to the auctioneer during the auction. At the close of the auction the
> auctioneer takes the highest bid and attempts to complete the transaction.
> This might involve verifying the participant's current authority
> to execute
> the transaction which may have changed since the time the bid was made.
>
> The concept of 'session' and 'login' is not a helpful one with respect to
> authorization. It is specifically a feature of authentication credentials.
>
>
> Phillip Hallam-Baker
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
>
>
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > Sent: Monday, March 12, 2001 10:19 AM
> > To: 'security-use@lists.oasis-open.org';
> > 'security-core@lists.oasis-open.org'
> > Subject: Requirement for Isolated Request for Authorization Atributes
> >
> >
> > In last week's Core Assertions concall there was some
> > discussion about the
> > idea of requesting Authorization Attributes for a user who is
> > not currently
> > logged in. I have a recollection of someone on a Use Case
> > concall a few
> > weeks ago saying this was an important requirement.
> > Unfortunately I do not
> > remember who it was. It was pointed out that the current use
> > cases do not
> > contain this element.
> >
> > Obviously a request of this type could be used as a performance
> > optimization, but does someone have another scenario in mind?
> > I hope no one
> > is planning to use SAML for provisioning. Based on current
> > thinking, I don't
> > think this will work.
> >
> > As I was writing this, I realized that perhaps what was intended was a
> > business transaction scenario, for example: UC-2-08:ebXML,
> > currently in the
> > issues list. In this case, the PDP may retrieve the
> > Authorization Attributes
> > after having received an ebXML message from the user.
> >
> > Are there any other use cases which involve the request of
> > Authorization
> > Attributes when an Authentication Assertion has not
> > previously been issued?
> >
> > Hal
> >
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to:
> > security-core-request@lists.oasis-open.org
> >
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC