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

Picking just one topic inline.

ext Tschofenig, Hannes wrote:
>>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.

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 26 Oct 2005 18:57:10 +0300