Subject: AW: [Geopriv] common-policy update

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 21 Oct 2005 16:38:11 +0200

hi martin, 

please find some comments inline:

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

currently we define the following:
"

if the condition is omitted, identities are not
                        considered and, thus, the condition matches any
user, authenticated or not.
"

in old versions of the document we had a dedicated identifier for this
purpose. in the more recent versions we omit it and defined it
differently. 

i added an example to the draft to make it clearer. 

do you have a problem with this approach? 

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

these rules are not identical. 
the first one would match any authenticated identity. the second one
matches authnenticated AND unauthenticated users. 

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

this would be a rule that always matches. 

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

i have now added that the combination of id and domain must not appear. 

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

this is an interesting question that needs to be discussed. 
in some sense this is a question for the using protocols that use the
common policy framework since they need to map the identities to the
respective scheme. 

> 
> Is //sphere language dependent?
> 
no, it is not language dependent. 

>     <sphere xml:lang="en" value="work"/>
> 
> ...or is this a simple string matching operation?
simple string comparison. 

> ...or are you going to use a registry for these values?
no registry defined - could be discussed .

i added some text. 

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

your suggestion regarding the xs:token feature is certainly helpful. 
a few of them are in the current xml schema based on your proposal.
maybe more can be done to the xml schema in the draft to avoid
ambiguity. 

ciao
hannes

> 
> 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.priv.at/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: Aki Niemi <[email-masked]>
Date: Wed, 26 Oct 2005 18:57:10 +0300

Picking just one topic inline.

> common policy framework since they need to map the identities to the

This has been discussed already many times, and we have concluded that 
making authentication mechanisms visible in common policy for the 
authorization rulemaker serves no purpose.

These authorization rules will be edited by ordinary users who will not 
understand what x509 vs. Basic vs. Digest vs. Kerberos means. It is 
really up to the using protocol to define how to map various identities 
derived from various authentication mechanisms (i.e., a "username" param 
of Digest, a SubjAltName from a cert and so on), and the users simply 
match identities knowing they are properly authenticated.

I would also argue that if you match based on something other than an 
identity, e.g., some role or trait, then that does not even belong to 
the identity condition, but an extension (like <trait> condition or 
something) is needed.

Cheers,
Aki