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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: The Hal/David model


Thanks, David.  I agree that we need to start being more disciplined about
using common terms, and will try my best to do so.

I think that we're using the word 'entity' in places where it would be
better to be more specific.  For example, we could use 'Principal' or 'User'
instead of 'Entity' in the definition of Authentication Assertions.  I think
we need both 'users' and 'principals/subjects', because we have separate use
cases for each - SSO doesn't really apply to processes, only humans.  Or, if
we're going to continue using 'entity', we need an entry in the glossary for
it.

Authentication Assertion: Should mention the fact that the data included
represents the type of authentication that was performed by the entity.

Principal: I think that we have consensus that our spec will be applicable
to problem domains where the thing that is being authenticated/authorized is
not a human being.  So that's where the terms Principal and Subject enter
into the discussion.  As far as I can tell, these terms have been taken to
mean different things in different areas of security.  I only think it is
important that we are clear about when we are talking about a human being
specifically, or any type of client (human, software, ...).

I prefer the first definition of 'Credential', except where it gets involved
in authorization.  So I agree with: "Data that is transferred to establish
the claimed identity of an entity".  Maybe 'entity' could be more clear.  My
problem with the second definition is that it seems to apply to things that
aren't used for authentication.

Policy Enforcement Point: Seems like it would be clearer to represent in
terms of 'users, principals, and resources' rather than 'initiator and
target'.

Time Out: I think of this scoped the same way as log-on our log-off - where
it has to do with a user's session within a security domain.  This is not
necessarily related to an authentication assertion.  I think what you've
described is another type of timeout which will need to be specified as part
of our design.

User: Should always be human.

There is a class called Authentication Authority on the class diagram that
doesn't have a corresponding glossary entry.

Doesn't the user have an association with the Authorization Authority just
like the Authentication Authority.

Should the PEP have an association with the Authentication Assertion?

Should the user have an association with the User Session?

- Darren



> -----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
> >
>
>



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


Powered by eList eXpress LLC