RE: Requirement for Isolated Request for Authorization Atributes

[Philip Hallam-Baker <pbaker@verisign.com>]

It appears to me that what is going on in that case is out of scope
definition of architecture, in particular assertion architecture in the
requirements group. 

The decision to differentiate between the two in the use case nomenclature
is reasonable, the 'decision' that the definition of what an assertion is be
specified by the use case group is utterly unreasonable.

What you define as an 'authorization assertion' is in fact an Authorization
decision, as the definition itself as specified makes clear.

An authorization assertion as the term is gernerally understood strongly
implies the union of the set of authorization decisions, authorization
attributes and other authorization data YTBD.

	Phill


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: Monday, March 12, 2001 3:36 PM
> To: Philip Hallam-Baker; 'Hal Lockhart';
> security-use@lists.oasis-open.org; security-core@lists.oasis-open.org
> 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
> > >
> >
> >
>

Phillip Hallam-Baker (E-mail).vcf