Subject: naming attributes

From: Leif Johansson <[email-masked]>
Date: Tue, 11 Jul 2006 16:43:55 +0200

During the wg yesterday I was asked to forward my comments regarding
naming attributes to the list.

As far as I understand the point of the naming api extension is to
treat a name as an opaque extracting name attributes by attribute
identifier. There are several obvious examples of objects which could
be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs,
LDAP entries etc.

My problem is with the choice of OIDs as name attribute identifiers
is that several of the obvious examples don't use OIDs as their
native attribute identifiers. I would argue that using OIDs will
only get us into a rat-hole of having to maintain mappings from
OIDs to whatever the native name uses. Instead I would propose
using a URN which both provides a structured and managed namespace
aswell as including the OID namespace by reference.

	Cheers Leif

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Jul 2006 10:31:17 -0500

> aswell as including the OID namespace by reference.

OTOH there are several obvious examples that do use OIDs as their native
attribute identifier (SANs, EKUs).

What to do?

The API being proposed is not a protocol, and its attribute identifiers
aren't used on the wire as an inherent result of their use in the API
(though where they map directly to actual uses on the wire specified in
other protocols then their use in the API will relate to their use on
the wire).

So it doesn't really matter what these identifiers are.

They could be anything, even octet strings, provided that we can
reasonably manage a) the namespace of attribute identifiers, b) the
mapping between specific instances of attribute identifiers and the
things they map to.

The GSS-API uses OIDs for other things, so it seemed natural to use
those here.  From an application developer's p.o.v. what matters is that
the OIDs have symbolic names (GSS_C_...) so that application developers
don't have to know the specific forms of these identifiers.

So, from an API design p.o.v., as long as we have symbolic names for
them then we shouldn't care whether we use OIDs or URNs or whatever.

But I see no advantage to URNs over OIDs.  There will be cases where the
attribute identifiers in the API could map directly onto protocol-level
identifiers, and there will be cases where they may not.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Jul 2006 18:10:34 +0200 (MET DST)

> > aswell as including the OID namespace by reference.

URN might be somewhat self-descriptive, OIDs are never self-descriptive.
OTOH, OIDs are fairly small/short comparison of OIDs is foolproof and
OIDs themselves do not have any I18N/L10N issues (attribute values may still
have them).

It should be fairly easy to assign OIDs for attribute identifiers that
do not have them yet in the IETF GSS-API OID-space.

However, independent of what one choses, I don't see a way to save
application programmers from maintaining a mapping, because semantics
and code to process particular attributes will have to be programmed,
no matter what.

btw. some of the attributes may not be single instances, but instead
come in sets or sequences.  How is the set/sequence traversed, and
what about the ordering of a sequence (i.e. sets should be distinguishable
from sequences at the API level).

> identifiers, and there will be cases where they may not.

The only conceivable advantage is the ease for vendors to come up with
private extensions that are somewhat self-descriptive.  It is likely
a small Google-advantage if you need to find the spec.

For the existing GSS-API architecture, OID-based tags are the more
consistent fit, and I would prefer them.

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Tue, 11 Jul 2006 19:05:22 +0200

> and code to process particular attributes will have to be programmed,

Not true. In the SAML-assertion wrapping case the api could use an
underlying SAML-api which extracts attribute values based on URNs.
No mappings there.

>> identifiers, and there will be cases where they may not.

Note that URNs include OIDs by reference so using URNs don't preclude
using OIDs.

I guess what I am arguing for is both to include a larger namespace and
thereby to avoid having to define attribute semantics in many cases.

	Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Jul 2006 19:28:25 +0200 (MET DST)

> underlying SAML-api which extracts attribute values based on URNs.

I don't understand.
We were discussing what the application caller above GSS-API will
have to supply, and if the application caller cares at all about
a particular attribute, it will have to implement semantics to
interpret attribute values.

Your descriptions sounds like an implementation detail how the
GSS-API layer passes down the request for an attribute into
an underlying SAML-api.

What you seem to be calling for is the possibility to transfer native
labeling and attribute values between a knowing application and
a particular mechanism below GSS-API and not have to go through
an additional abstraction layer (which would require mapping).

Basically, you seen to be looking for a common API call rather
than a real abstraction (which could, in theory, provide some level
of portability/independence of the nature of the attribute).
One requirement for a working abstraction would be that the
attribute tags are all of the same type (OIDs would be best),
and attribute values should have a compatible representation
(i.e. octet string), canonical encoding and can be processed
in an opaque fashion (equal or not equal in the octet string
representation).

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Tue, 11 Jul 2006 19:48:30 +0200

> interpret attribute values.

True.

> GSS-API layer passes down the request for an attribute into

In several interesting cases I'm arguing that the GSS naming api
could be a very light shim-layer to an underlying api, yes. I argue
that adding the requirement to manage a potentially large attribute
mapping table is something which would be nice to avoid.

> an additional abstraction layer (which would require mapping).

I am hoping that the GSSAPI naming api won't have to redefine a
large set of attributes which has been defined in several other
forms already, including LDAP and SAML.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Jul 2006 12:34:26 -0500

> and code to process particular attributes will have to be programmed,

Mappings would be done mostly in the mechanism/mechglue.  E.g., you
might have a name attribute corresponding to "MS PAC" that gives you
that PAC payload, but also name attrs corresponding to individual items
therein; the application would be responsible only for knowing the attr
symbolic names and the encoding of the values.

> from sequences at the API level).

The draft has GSS_Get_name_attribute() output a SET OF values; the
proposed C bindings of it outputs one value per-call and a
boolean/counter ('more') to indicate that it should be called again to
retrieve additional values.

> a small Google-advantage if you need to find the spec.

That might actually be useful.  Perhaps we should ask SAML weenies about
this.

> consistent fit, and I would prefer them.

I agree, but we should consider the attribute self-description angle.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Jul 2006 12:40:10 -0500

> Note that URNs include OIDs by reference so using URNs don't preclude

There's no real good reason for using OIDs other than that they're
already used in the GSS-API so they are an easy fit.

> thereby to avoid having to define attribute semantics in many cases.

That's unconvicing to me, but Martin's point about attribute identifier
self-description may be.  Think of an attribute identifier that tells
you, essentially, how to extract some element of a larger structure
delivered/authenticated by a mechanism.

Nico
--