Subject: [Geopriv] WGLC on Common Policy

From: Allison Mankin <[email-masked]>
Date: Mon, 20 Feb 2006 09:39:42 -0800

Geopriv Folks,

We are starting the WGLC on 

draft-ietf-geopriv-common-policy-07.txt 

This was just revised to have its last issues 
reflected, and we believe it is now in shape for
final working group review. 

Please send an ack to indicate a positive for going
forward, even if you have no comments now, and of
course, comments if you have any.

We'll conclude this WGLC on Monday, March 6.

The Chairs

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 21 Feb 2006 12:43:35 +0100

hi allison, 

thanks for starting the WGLC.

aki provided comments that i incorporated immediately into the draft. here is an updated version:
http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-08.txt
http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-08.html

as you saw from my separate mail they are editorial in nature. 

i plan to add further comments immediately to the draft to submit a new version before the deadline. 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: Allison Mankin [mailto:[email-masked]] 
> Gesendet: Montag, 20. Februar 2006 18:40
> An: [email-masked]
> Betreff: [Geopriv] WGLC on Common Policy
> 
> Geopriv Folks,
>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 21 Feb 2006 15:39:15 +0100

Hi Martin

thanks for your review. 
 
I am aware of the SAML approach for dealing with identities. 
At the last IETF meeting we discussed the identity issues and concluded that we 
want to go for a URI approach. The content of the scheme attribute is thereby mergened into the URI. 

We should probably indicate how to extend the common policy document regarding new identifier schemes in more detail. 
To me it would be reasonable to register a new URI scheme (as described in RFC 4395). I could, however, imagine that such a URI scheme is quite artifical and not useful for other applications outside the scope of the Common Policy authorization policy family Is this a problem? What do other folks think about extensibility topic?

A few minor comments below:

> Von: Thomson, Martin [mailto:[email-masked]] 
> Gesendet: Dienstag, 21. Februar 2006 05:47
> An: [email-masked]; [email-masked]
> Betreff: RE: [Geopriv] WGLC on Common Policy
> 
> Maybe predictably, I have comments on the draft.
> 
> This document provides a skeleton for authorization policies. 
>  Key to this is the way in which extensibility is handled.  
> The top level structure of an instance document is geared for 
> extensibility - new types of conditions, actions and 
> transformations can all be added easily.
> 
> The way that identity has been addressed is not extensible.  
> The issue was raised at the last meeting and the decision 
> made was to sidestep the issue by requiring that identity be 
> expressed as a URI.
> 
> I have previously identified a use-case where identity is not 
> easily expressed as a URI.  If common-policy is going to be 
> used elsewhere (and I know of at least one standards body 
> that is considering it), then extensibility is critical to 
> support the types of identity that are used in that domain.
> 
> The SAML 2.0 <Subject> is a good example of how identity can 
> be conveyed in XML.  SAML 2.0 includes URNs for Email 
> Address, X.509 Subject Name, Windows Domain Qualified Name, 
> and Kerberos Principal Name, of which only email address is 
> covered by common-policy.  
> 
> I am not suggesting that common-policy must include these 
> identity types; rather, I am saying that common-policy must 
> not prevent these types from being defined should they be required.
> 
> You can extend the current system, but it isn't easy, or 
> elegant.  The two alternatives that come to mind are: getting 
> a new scheme registered per RFC 4395, or using a 'data:' URI.
> 
> I even have a concrete suggestion; one I suspect was not made 
> public.  I did discuss this at length with one of the authors:
> 
>   <identity>
>     <allow>
>       <user name="[email-masked]"/>
>       <domain name="example.net"/>
> 	<vnd:extension>any content</vnd:extension>
>     </allow>
>     <deny>
>       <user name="[email-masked]"/>
>       <domain name="phishing.com"/>
>     </deny>
>   </identity>
> 
> The method for evaluating this is quite simple: the condition 
> matches if the identity matches any "allow" statement and no 
> "deny" statement.  If "allow" is empty, it matches any 
> authenticated identity; if "deny" is empty (or not present) 
> it matches none.  Any extension that is not understood can be 
> ignored in the "allow", but must cause the rule to fail if it 
> is in the "deny".
> 
> This also allows for more meaningful element names.  They 
> could even be more specific.
> 
> ~
> 
> Now with that out of the way, I have one last quibble and a typo.
> 
> Section 5 states that there should be "No all-except 
> conditions"; Section 7.1.4.2 shows an example that is 
> almost-all-except.  It's too fine a point to argue that 
> "all-authenticated" is not "all"; it's an all-except because 
> an "except" requires authentication to enforce.  Is identity 
> an exception to this non-goal as Section 5 seems to imply?

Aki suggested to delete this item. what do you think about his suggestion?  

> The reference to Figure 1 is missing a space, as in "shown 
> inFigure 1".

Fixed. 

Ciao
Hannes

> 
> Cheers,
> Martin
> 
> > -----Original Message-----
> > From: Allison Mankin [mailto:[email-masked]]
> > Sent: Tuesday, 21 February 2006 4:40 AM
> > To: [email-masked]
> > Subject: [Geopriv] WGLC on Common Policy
> > 
> > Geopriv Folks,
> > 
> --------------------------------------------------------------
> ----------------------------------
> 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]
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Feb 2006 15:33:16 -0600

The URNs are used to identify the type of content, they aren't the actual content.  For instance, the URN for Kerberos principle name is:

	urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos

Sorry for the confusion.

> Howdy,
> 	Possibly I am missing something here, but is the use-case where
> identity
> is not easily expressed as a URI something different from the SAML 2.0
> case below?
> For each of the email address, kerberos principle name, etc, I don't see
> the problem.
> URNs are, after all, a type of URI, and my understanding is that they are
> perfectly
> legal in xs:anyURI constructs.
> 	Have I misunderstood you?
> 				regards,
> 					Ted Hardie
> 
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Feb 2006 15:54:04 -0600

Certainly, some more information on URIs would be useful.  Artificially creating URI schemes does seem pointless however for some applications, particularly when compared to the alternative, which is the creation of an extension namespace - IETF/IESG expert review is a little heavyweight methinks.

I still don't see why the <one>, <many> approach must be adhered to.  What about the merits/disadvantages of the alternative that I suggested?

Oh, and I agree with Aki.  Email troubles meant that I missed his original email (and several others).  James and I were/are extremely annoyed with our IS about that particular problem.

> From: Tschofenig, Hannes [mailto:[email-masked]]
> Sent: Wednesday, 22 February 2006 1:39 AM
> To: Thomson, Martin; [email-masked]; [email-masked]
> Subject: AW: [Geopriv] WGLC on Common Policy
> 
> Hi Martin
> 
> thanks for your review.
> 
> We should probably indicate how to extend the common policy document
> regarding new identifier schemes in more detail.
> To me it would be reasonable to register a new URI scheme (as described in
> RFC 4395). I could, however, imagine that such a URI scheme is quite
> artifical and not useful for other applications outside the scope of the
> Common Policy authorization policy family Is this a problem? What do other
> folks think about extensibility topic?
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Feb 2006 16:43:33 -0600

> 
> The basic test is that removing a rule can never increase permissions.
> This requirement is met here.

Just a thought:

I think that your statement is worth including in the document (under "Permit only" perhaps):
  "... Removing a rule can never increase permissions."
------------------------------------------------------------------------------------------------
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]