Subject: AW: AW: AW: [Geopriv] common policy document

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 13 Jul 2005 14:52:45 +0200

hi henning, 

the <any-identity> element is a condition element that matches any
authenticated and asserted identity.

as an example, the following two rules (that are shown in ruleset (1))
are equivalent to rule, which uses the <any-identity> element, shown in
ruleset (2) :

1) WITHOUT <any-identity>:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">

  <rule id="f3g44r2">
    <conditions>
      <identity/>
    </conditions>
  </rule>

  <rule id="f3g44r2">
    <conditions>
      <asserted/>
    </conditions>
  </rule>
</ruleset>

1) WITH <any-identity>:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">

  <rule id="f3g44r2">
    <conditions>
      <any-identity/>
    </conditions>
  </rule>
</ruleset>

with more complex rules (e.g., <any-identity/> with multiple
<except-domain> elements) it would be necessary to replicate them. 

does this make more sense? 

ciao
hannes

> To help the discussion along, can you summarize the two 
> options or given 
> an example?
> 
> 
> Tschofenig, Hannes wrote:
> > hi jari, 
> > 
> > thanks for your comment. please find a short response below: 
> > 
> > ~snip~snip~
> > 
> > 
> >>I'll have another question about common-pol-05. I don't understand
> >><domain>s in <any-identity>. It seems to me that they break the
> >>consistent model of "anything", why can't you get similar thing with
> >><domain>s in <identity> ?
> > 
> > 
> > this is a very good question. the <any-identity> was proposed as a
> > condition element that matches any authenticated and 
> asserted identity.
> > the <any-identity> is basically a short version of 
> <identity/> combined
> > with <asserted/>. the <any-identity> with the domain 
> element can also be
> > replaced by the respective combination of <identity> and <asserted>.
> > 
> > hence, your comment raises the question whether we can 
> actually omit the
> > <any-identity> element. at the interim meeting there was no comment
> > regarding this issue. what do you think?
> > 
> > ciao
> > hannes
> > 
> >>br,
> >>Jari
> >>
> >>
> > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jul 2005 12:04:11 -0400

Having two ways to do the same thing seems sub-optimal. This is already 
confusing enough. If anything, it would make sense to have a more 
orthogonal specification of identities and their strength, such as

<identity strength="asserted">
    <id entity="foo@bar">
</identity>

---

From: Aki Niemi <[email-masked]>
Date: Thu, 14 Jul 2005 14:20:01 +0300

Hi,

I'm still confused about the need for "asserted" and "authenticated" 
instead of simply "asserted". To an unsophisticated rulemaker they sound 
the same. Do we have clear use cases for justifying being able to 
distinguish between a 3rd party assertion and a home-grown assertion 
(e.g., Digest authenticated username)? If not, these two can be folded 
together.

But if the distinction between "asserted" and "authenticated" is needed, 
then a better way is to add a 'strength' parameter to the <identity> 
element, as Henning suggested.

That said, I would propose a slightly different construct where 
<identity> is used for all identity-related matches:

<!-- Identity can match ordinary single identities -->
<identity>
    <id entity="[email-masked]" />
    <id entity="[email-masked]" />
</identity>

<!-- ...or use domain wildcards... -->
<identity>
    <wildcard domain="example.com">
       <except entity="[email-masked]" />
       <except entity="[email-masked]" />
    </wildcard>
</identity>

<!-- ...or the 'any-identity' which is really a global wildcard -->
<identity>
    <any>
       <except domain="foobar.com" />
    </any>
</identity>

This seems a bit more logical compared to splitting them up, i.e., <id> 
and <domain> under <identity> and <any-identity> as a separate condition.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 10:51:34 -0400

I generally agree with Aki - I just can't see explaining this to normal 
users. (They won't see the XML, but the user interface still has to 
somehow reflect this. Including some verbiage about Digest and header 
assertions is going to be completely useless and will just lead to 
people at best guessing or leaving it completely open.)

Plus, there will likely be other shades of authentication in the future 
(asserted by P- headers vs. more cryptographic assertion by third 
parties). I don't think real users will understand the differences. I 
thought we had earlier agreed that trying to do strength of 
authentication or assertion is not explainable and implementable.

I think we have to trust the server to either do the right thing for 
anything beyond unauthenticated "believe me" authentication. Some admins 
will set the threshold high (must have identity signed by a 
government-approved CA that requires a DNA sample and FBI background 
check) and others will allow P-Asserted from certain domains they trust.

There are other complications here. Rules are supposed to be portable, 
but not every server will support every means of authentication. 
Suddenly, rules that worked in one place will mysteriously start 
rejecting subscriptions after copying them elsewhere.

In any event, it would seem odd to have to list the same person in three 
categories (no auth, asserted, authenticated). At least, these would 
have to be ordered, so that (say) asserted also includes stronger 
authentication.

Henning

Aki Niemi wrote:
>> Having two ways to do the same thing seems sub-optimal. This is 
>> already confusing enough. If anything, it would make sense to have a 
>> more orthogonal specification of identities and their strength, such as
>>