Subject: RE: [Geopriv] common-policy update

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2005 00:25:19 -0500

Hi Hannes,

I definitely think that this version of the draft is a very usable.  I can also confirm that the examples and schema are valid (Xerces assures me that this is so).

My comments are mostly nuts and bolts sort of stuff, I haven't picked over the text yet, my main concerns are with the schema and how it is to be interpreted.

...

"<many/>" is described as "matching any authenticated user", therefore when it isn't present does this mean "matching any user", or "matching no user".

Similarly, when //many isn't specified, as in example 6, what does this imply?  Are the following two fragments identical?

    <conditions><many/><sphere value="work"/></conditions>
    <conditions><sphere value="work"/></conditions>

In the same vein, is this the most permissive possible authorization policy? Or, is it the least permissive? (it's definitely valid)

    <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
      <rule id="0"></rule>
    </ruleset>

In the //except element, what are the implications of specifying both id and domain?  Three contrived examples (all valid):

    <except id="[email-masked]" domain="example.com"/>
    <except id="[email-masked]" domain="example.com"/>
    <except id="joe" domain="example.com"/>

Understand that XML Schema can't express a mutual-exclusion constraint on these (that is one of the strengths of Relax NG).

Suggest that you instead use elements for domain and (for want of a better name) individuals. 

The //one and //many elements don't allow for extensible content.  How do I specify a user who is authenticated by means of providing an X.509 certificate?   Would this suffice?

    <one id="subjectAltName" scheme="x509"/>

..."x509" isn't a registered scheme though.

Is the intent that the //identity element is not used for these alternate authentication modes, or that common-policy specifically forbids these?  I'll admit that the case for putting something like SAML elsewhere is might be OK, but do you want to extend that to all types of identity information?

Is //sphere language dependent?

    <sphere xml:lang="en" value="work"/>

...or is this a simple string matching operation?
...or are you going to use a registry for these values?

Suggest that you use xs:token more widely; for //sphere and @scheme primarily.  Here is my idea:

  <!-- //entity@scheme -->
  <xs:simpleType name="schemeType">
    <xs:list>
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <!-- scheme from RFC 3986 -->
          <xs:pattern value="[a-zA-Z][a-zA-Z0-9+-\.]*"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:list>
  </xs:simpleType>

The cardinality rules for //conditions are a little strange:

    (validity?|sphere*|identity?|<other>*)+

...at least normalize it to something like:

    (validity|sphere|identity|<other>)*

...although I suspect that you meant to ensure that at least _something_ is included in a rule:

    (validity|sphere|identity|<other>)+

...however I would prefer that it were ordered to match the bulk of the examples (the examples aren't consistent though, some would need to be changed).

   (identity?, sphere*, validity?, <other>*)

Suggest that you use xs:ID for the /ruleset/rule@id type.  This forces a uniqueness constraint, which I would recommend that you include if this type isn't used.

For domains, is "example.com" equivalent to "example.com.", or does it depend on context (that is, what search suffixes are present)?

I have attached my suggested changes to the schema (and examples to match).  The changes are less severe than it might seem, the only real change is to //one and //many elements.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes
Sent: Thursday, 13 October 2005 4:55 AM
To: [email-masked]
Subject: [Geopriv] common-policy update

hi all, 

we have worked on a draft update that can be found at: 
http://www.tschofenig.com/TEMP/geopriv/

this directory contains the text/html files and the xml schema including
some instance documents (as examples). 
(i used the xml editor oxygen to validate the instance documents against
the xml schema. they worked fine.)

the update includes the modified text for the identity condition section
and the respective changes throughout the document. this text contains
the functionality that was agreed during the paris ietf meeting (with
the minor comment that the discussion about the tel uri's was a bit
fuzzy and this part might be a bit shaky). 

i will setup an issue tracker (if needed) to make sure that we capture
all comments. 

note that we have not yet submitted this draft version. we want todo a
document review before we submit it just before the deadline. 

ciao
hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Thu, 13 Oct 2005 10:34:06 -0600

Would it be OK to share this document with the OGC membership? There are 
several reasons for doing this, one of which is that we have a very active 
group working GeoDRM (Geo Digital Rights Management). They have developed 
use cases and are working on a reference model for the geospatial domain. I 
believe the work of the GeoPRIV members and the OGC members are synergistic.

Thanks and regards

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 12, 2005 11:25 PM
Subject: RE: [Geopriv] common-policy update

> Hi Hannes,
>
> I definitely think that this version of the draft is a very usable.  I can 
> also confirm that the examples and schema are valid (Xerces assures me 
> that this is so).
>
> My comments are mostly nuts and bolts sort of stuff, I haven't picked over 
> the text yet, my main concerns are with the schema and how it is to be 
> interpreted.
>
> ...
>
> "<many/>" is described as "matching any authenticated user", therefore 
> when it isn't present does this mean "matching any user", or "matching no 
> user".
>
> Similarly, when //many isn't specified, as in example 6, what does this 
> imply?  Are the following two fragments identical?
>
> In the same vein, is this the most permissive possible authorization 
> policy? Or, is it the least permissive? (it's definitely valid)
>
> In the //except element, what are the implications of specifying both id 
> and domain?  Three contrived examples (all valid):
>
> Understand that XML Schema can't express a mutual-exclusion constraint on 
> these (that is one of the strengths of Relax NG).
>
> The //one and //many elements don't allow for extensible content.  How do 
> I specify a user who is authenticated by means of providing an X.509 
> certificate?   Would this suffice?
>
> Is the intent that the //identity element is not used for these alternate 
> authentication modes, or that common-policy specifically forbids these? 
> I'll admit that the case for putting something like SAML elsewhere is 
> might be OK, but do you want to extend that to all types of identity 
> information?
>
>
> ...however I would prefer that it were ordered to match the bulk of the 
> examples (the examples aren't consistent though, some would need to be 
> changed).
>
> Suggest that you use xs:ID for the /ruleset/rule@id type.  This forces a 
> uniqueness constraint, which I would recommend that you include if this 
> type isn't used.
>
>
> For domains, is "example.com" equivalent to "example.com.", or does it 
> depend on context (that is, what search suffixes are present)?
>
>
> I have attached my suggested changes to the schema (and examples to 
> match).  The changes are less severe than it might seem, the only real 
> change is to //one and //many elements.
>
>
> Cheers,
> Martin
>
> http://www.tschofenig.priv.at/TEMP/geopriv/
>

--------------------------------------------------------------------------------