RE: The Hal/David model

[Darren Platt <dplatt@securant.com>]

Comments on Nigel's points (sorry, just getting caught up on email):

> The model shows an Authentication Authority having a relationship
> with Authentication Assertions. By symmetry, I would have expected
> to see an Attribute Authority having a similar relationship to Attribute
> Assertions - instead I see Authorization Attributes. This seems
> a little strange to me.

I think the things an attribute authority distributes should be called
attribute assertions also.


> I am not sure that it is worth trying to separate Authorization Attributes
> and Authorization Assertions. The definitions try to distinguish the two
> by making the latter a policy (such as user "noddles" is granted
> "execute"
> on "/usr/bin/guitar") and equating the former to an attribute (circular?)
> such
> as role, title... To me "execute on /usr/bin/guitar" is another attribute
> of noddles.

I believe a statement such as such as "user 'noddles' is granted 'execute'
on '/usr/bin/guitar'" is a statement of policy.  This statement is not that
different from "users who are 6 feet tall are granted 'execute' on
'/usr/bin/guitar'" or "users who have the role 'musician' are granted
'execute' on '/usr/bin/guitar'".  These latter two are clearly require a
'decision' to enforce and are therefore the input of the policy decision
point.  I therefore don't think that this is something a PDP would pass to a
PEP, rather something a PDP might pass to another PDP.  By their names, PDPs
and PEPs seem to me to be abstractions based on their functionality - so a
decision point evaluates policy and makes a decision, and an enforcement
point applies the decision.

As we've discussed, in actual deployments, several these 'interfaces' (PDP,
PEP, Attribute Authority,...) could implemented by one component.  IMHO,
that is all the more reason to define these interfaces based on their
functionality at this stage of analysis, and then we can combine them as we
see fit later in design.


> A comment is also made about equating authorization assertion with
> authorization
> decision.

I think the Authorization Decision, passed between the PDP and PEP in Hal's
model, is a yes/no answer.  It may also contain an authN assertion, a
reference to an authN assertion, a reference to a specific authorization
'question', a validity period.  To me this is the result of a policy
evaluation, and while there are times it can look similar to an policy
statement, it is not used for the same thing.  There will be scenarios where
the person who is asking whether a user is allowed to do something should
only receive the answer to that question - not a policy for that user or
that resource.


> identity. I propose
> the following: (definition for principal)
> "An authenticable identity of a system entity within the security domain."

I agree.

Regards,

Darren


> -----Original Message-----
> From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
> Sent: Thursday, March 15, 2001 2:51 PM
> To: 'Orchard, David'; security-services@lists.oasis-open.org
> Subject: RE: The Hal/David model
>
>
> I have a few comments on this.
>
> The model shows an Authentication Authority having a relationship
> with Authentication Assertions. By symmetry, I would have expected
> to see an Attribute Authority having a similar relationship to Attribute
> Assertions - instead I see Authorization Attributes. This seems
> a little strange to me.
>
> I am not sure that it is worth trying to separate Authorization Attributes
> and Authorization Assertions. The definitions try to distinguish the two
> by making the latter a policy (such as user "noddles" is granted
> "execute"
> on "/usr/bin/guitar") and equating the former to an attribute (circular?)
> such
> as role, title... To me "execute on /usr/bin/guitar" is another attribute
> of noddles.
>
> There have been examples of both kinds of assertions on the
> core-assertion
> mailing list and Phill Hallam-Baker has pointed out the distinction is
> blurred
> - it would be hard to design a framework that could do one, but not the
> other.
> Therefore to me, it is not worth trying to make a distinction.
>
> A comment is also made about equating authorization assertion with
> authorization
> decision. To me, this is up to the interpreter of the assertion.
> I could get
> this and
> treat it as an access control decision. Equally, it could be
> processed by a
> PDP
> to produce a "yes/no" answer. Therefore, I would say that not all
> assertions
> of this
> class would necessarily be authorization decisions.
>
> Finally I have a comment on the definition of Principal. (This is with
> apologies, since
> I was on the conference call.) On reflection, I think it is worth
> capturing
> the idea of
> authentication in the definition. If we are going to be making assertions
> about principles,
> it doesn't really make sense if those principles cannot be
> authenticated to
> gain the
> privileges implied by the assertion. Also the term "instantiation" for me
> does not
> capture the idea that a system entity may have more than one principle
> identity. I propose
> the following:
> "An authenticable identity of a system entity within the security domain."
>
> Nigel.
>
> > -----Original Message-----
> > From: Orchard, David [mailto:dorchard@jamcracker.com]
> > Sent: Wednesday, March 14, 2001 10:32 PM
> > To: security-services@lists.oasis-open.org
> > Subject: RE: The Hal/David model
> >
> >
> > I have updated the use case team's domain model as a result
> > of today's use
> > case telecon.  Excellent progress all!
> >
> > Cheers,
> > Dave
> >
> > > -----Original Message-----
> > > From: Orchard, David [mailto:dorchard@jamcracker.com]
> > > Sent: Monday, March 12, 2001 8:32 PM
> > > To: security-services@lists.oasis-open.org
> > > Subject: RE: The Hal/David model
> > >
> > >
> > > I have updated the domain model as best I can with the
> > various emails,
> > > glossary, pdfs, etc. that are available.  I don't yet have a
> > > usable copy of
> > > Visio, so the diagram will come from togetherJ for the near future.
> > >
> > > This is an imperfect job as I was a bit overwhelmed by the
> > > glossary and all
> > > the discussions on terminology differences.  I started
> > bottom-up (what
> > > glossary terms are required) rather than try to fit all the
> > > glossary terms
> > > in the diagram.
> > >
> > > I have liberally and flagrantly infringed copyrights by copying some
> > > material from the mailing list(s) and the glossary.  I also
> > > copied from the
> > > glossary rather than refering to it, so that reviewers could
> > > combine all
> > > their comments together.   I also added issues where
> > > definitions seemed
> > > vague/confusing/etc.
> > >
> > > This is complete in that every item and major relationship
> > > listed in the
> > > class diagram has a glossary entry.
> > >
> > > Process going forward: I expect that once we come to
> > > agreement on what we
> > > mean by terms, we can then push them back to the glossary.
> > > Please provide
> > > plenty of feedback to the group on this.
> > >
> > > Suggestion for the use case chair and subcommittee: Very soon
> > > we start only
> > > allowing conversations about terms that are in the
> > > glossary/domain model.  I
> > > have been scanning various e-mails and notice many different
> > > synonyms, which
> > > I (and I'm sure other readers) would find confusing.  I
> > > suggest that the set
> > > of requirements we are now balloting is a candidate for this.
> > >  Terms like
> > > subject, policy-based disclosure, subject security
> > > attributes, parties,
> > > disclosure,  run-time, sharing, etc. are not currently in the
> > > domain model,
> > > nor in the glossary.  One person's run-time is another
> > > persons compile-time,
> > > etc.  Let's define these terms or not use them at all.
> > >
> > > Dave Orchard
> > > XML Architect
> > > Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
> > > p: 408.864.5118     m: 604.908.8425    f: 408.725.4310
> > >
> > > www.jamcracker.com - Sounds like a job for Jamcracker.
> > >
> > > > -----Original Message-----
> > > > From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> > > > Sent: Friday, March 09, 2001 9:04 AM
> > > > To: security-services@lists.oasis-open.org
> > > > Subject: The Hal/David model
> > > >
> > > >
> > > > People who attended F2F #1 will recall the diagram that Hal
> > > > Lockhart drew
> > > > up on the whiteboard.  It was something he and David Orchard
> > > > came up with
> > > > to help the use-case group settle on terminology and a rough
> > > > model of the
> > > > "things" we're discussing.  Fred Moses worked from his notes
> > > > to create the
> > > > following electronic version, which reflects a bit more of
> > > > the discussion
> > > > we had that day:
> > > >
> > > >    http://oasis-open.org/committees/security/docs/sstcach1.gif
> > > >
> > > > I'm sure we need more revisions to this diagram, but I would
> > > > like to work
> > > > towards consensus on the names for things and the
> > > > relationships between
> > > > them.  Please use this thread to discuss it, and we will take
> > > > it up as a
> > > > topic at the 20 March telecon.
> > > >
> > > > For starters:
> > > >
> > > > - On Tuesday, we discussed separating each box so that
> > > > there's no hint of
> > > > chronology.  This could mean, e.g., duplicating the "1"
> > > > callout so that
> > > > it's shown separately as the output of a credential collector
> > > > and the input
> > > > to an authentication authority.
> > > >
> > > > - I think the policy balloons should largely be in the "Not
> > > > SAML" layer
> > > > above.  Or is the XACML discussion precisely about whether
> > > > some of these
> > > > balloons should be in scope?  Can we give distinct names to
> > > > the different
> > > > types of policies?
> > > >
> > > > - What exactly do the input/output letters above refer to?
> > > >
> > > > - I think we *may* have consensus that the "SAML" box should
> > > > cover more
> > > > stuff to the left, e.g., it should cover the authentication
> > > > authority.  Comments?
> > > >
> > > > - Do we have consensus that SAML should cover the PEP box?
> > > >
> > > > Thanks to Fred for making this version; I think Hal and David
> > > > should now
> > > > take up any revisions we ask for.
> > > >
> > > > 	Eve
> > > > --
> > > > Eve Maler                                             +1
> > > 781 442 3190
> > > > Sun Microsystems XML Technology Development  eve.maler @
> > > east.sun.com
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > To unsubscribe from this elist send a message with the single word
> > > > "unsubscribe" in the body to:
> > > > security-services-request@lists.oasis-open.org
> > > >
> > >
> > >
> >
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
>