Subject: RE: [Geopriv] WGLC on Common Policy

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 20 Feb 2006 22:47:06 -0600

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?

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

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

------------------------------------------------------------------------------------------------
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: Ted Hardie <[email-masked]>
Date: Tue, 21 Feb 2006 10:42:47 -0800

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

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