[Geopriv] Re: AW: Authentication mechanisms visible or not? (was: Re: AW: [Geopr iv]common-policy update)

Hi,

ext hannes.tschofenig@gmx.net wrote:
> hi aki,
>
> i think we agreed to keep the common policy doc as simple as
> possible.
>
> however, there are some further issues that need to be addressed (as
> part of future work): - how extensible is the current document ? can
> we define new features (such as those raised in the past)? these
> extensions do not need to be developed right now. we might need to
> consider the feedback for the currently developed spec. first.

Extensibility is certainly an important topic. Expecially interesting is
how the rulemaker and the policy server find out about each others
supported features; expecting something to work and not finding out
before applying it won't seems like a bad thing to happen.

> - the user interface issue: sure, users are not going to make
> decisions about authentication mechanisms. but this might not be the
> only use case of the geopriv policies. in other use cases this could
> make a lot of sense. the saml guys, for example, believe that this
> work is useful. let us see what happens.

Are we going to make common-policy address all of those additional use
cases, or are we going to ship this thing in the near future?

> - martin's aspects about the identifiers is indeed interesting but
> might not be a topic for the common policy document. his problem is
> that the identifiers used in http and transport layer security do not
> match nicely with the identifiers used in the common policy document.

In some ways, SIP Digest suffers from the same problems. The "username"
used in Digest typically has no domain part, and worse, it may be
entirely different from the service identity of the user.

For example, my username in the system may be "apniemi", with which I
authenticate to the example.com system, but my service identity might be
"aki.niemi@example.com". Still, this is not a problem common-policy can
easily address.

As for identities used in certificates in transport security, there
might be a problem. Although the id attribute is a string, so if you
wanted to authorize an http server, shouldn't this do the trick?

<identity>
   <one id="location.server.example.com" scheme="http" />
</identity>

Note that this would still say nothing about whether this identity
is/was authenticated using an X.509v3 certificate, and I don't see why
it should.

> one solution might be to define a mapping in his http location
> delivery document to a uri/iri. martin, alternatively, asked whether
> one feasible approach would be to enhance the common policy used
> schemes to denote an x.509 distinguished name.

Yes, I realized this is what he was asking. But the example he gave
would match all requests whose identity was "subjectAltName" and came
using the x509 protocol... So I don't think that approach works well;
that information would need another way of representing anyway. IFF we
were to go back on the earlier decision that authentication mechanisms
are not visible in common-policy, that is.

> my conclusion: there is no disagreement and no problem just some
> topics that require more thinking. a draft review of the common
> policy document would not hurt as well.

I can agree to that, and take a personal action point to go through the
whole document with a fine-tooth comb, and not only the identity
section... ;-)

Cheers,
Aki

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 27 Oct 2005 13:47:47 +0300