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


Title: RE: The Hal/David model

Some comments interspersed with your message:

<TIM>The model should include "authenticator".  The authenticator is contained in the authentication assertion and relied upon by the PDP.  For instance, if the Principal has a public key, then it is an authenticator and is contained in the  authentication assertion and the PDP verifies that the Principal knows the corresponding private key.</TIM>

I don't think we should include an authenticator.  I do not see why one is required - we are asserting that an authentication has been done - and the assertion should be validated based on the trust relationship between the parties.

 

<TIM>The model should contain an attribute of the resource that is its "sensitivity".  Sensitivity reflects the harm that may result if the resource's methods can be executed by a Principal that does not have the appropriate privilege. </TIM>

Is this something that can be quantified?  How would it be represented?

 

<TIM>On the subject of "Primary domain".  The "Protocols" section contains definitions for "Primary domain", "Secondary domain", "Principal", "PEP", "PDP" and some others. </TIM>

I agree that we will need to have the concept of a 'primary' or 'home' domain as well as 'secondary' or 'remote' domains.

 

<TIM> I believe the definition of "Authorization assertion" that you have here is too limited.  This definition is resource- or ACL-orientated.  In S2ML and in your model, the authorization is more Principal-orientated. </TIM>

I'm not sure what you mean - can you give an example?  An authorization assertion is about an principal and a resource - I don't see how we are more oriented to one or the other until we have a design.

Regards,

Darren

 

 

 -----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Tuesday, March 13, 2001 8:45 AM
To: 'Orchard, David'; security-services@lists.oasis-open.org
Subject: RE: The Hal/David model

David - Some observations ...

The model should include "authenticator".  The authenticator is contained in the authentication assertion and relied upon by the PDP.  For instance, if the Principal has a public key, then it is an authenticator and is contained in the  authentication assertion and the PDP verifies that the Principal knows the corresponding private key.

The model should show "environmental data" available to the PDP.  Examples include "account balance", "time of day", etc..  Out of scope, no doubt.  But, I think the picture is supposed to show things that are out of scope in order that we can be explicit about what is and is not in scope.

The model should contain an attribute of the resource that is its "sensitivity".  Sensitivity reflects the harm that may result if the resource's methods can be executed by a Principal that does not have the appropriate privilege.

The model should contain a "session authority" that issues "session assertions" expressing the state of a user's session in the Primary domain.

On the subject of "Primary domain".  The "Protocols" section contains definitions for "Primary domain", "Secondary domain", "Principal", "PEP", "PDP" and some others.

I believe the definition of "Authorization assertion" that you have here is too limited.  This definition is resource- or ACL-orientated.  In S2ML and in your model, the authorization is more Principal-orientated.

The definition of (Security) policy should be more general.  It is the set of rules by which a PDP compares the privileges of the Principal with the sensitivity of the resource.

Best regards.  Tim.


-----Original Message-----
From: Orchard, David [mailto:dorchard@jamcracker.com]
Sent: Monday, March 12, 2001 11: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