I think the mapping should work for our purpose, where AA will know
which handle prefix to use. On the other hand, Itmight help to point
out that this is not a general mapping between the URI/DN and handle
as I originally thought. Instead, this is a mapping from URI/DN to
handles under a specific handle prefix.
Initially, I was looking for a single way to map those unique
identifiers, like DNs, into a single way into the handle name space. You
could maybe/probably find a scheme to do that by dedicating a single NA
to map certain URI schemas in.
However, we're not issuing the URIs as they already exist, but merely
binding attributes to those names.
Now, theoretically anyone in the world could potentially bind any
attribute to any unique name, and it becomes an issue that you only will
be interested in certain authorities to do that. It this case, a handle
system Naming Authority is not so much a keeper of the name, but a
keeper of certain name bindings that have a trust and application domain
as indicated by that NA.
I'm still struggling to find the right mental model here...
I'm still not clear on how to map attribute-<name, value> into
handle-<type, values>. It seems straightforward if the attribute-value
can be determined by a simple attribute-type. But the simple mapping
doesn't seem to be able to capture compound-attribute type such as:
<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"
NameQualifier=http://uchicago.edu/gridshib/idp> ....
</saml:NameIdentifier>where the attribute-type contains multiple URIs;
or attributed-<type, value> pair under nested context, such as:
<samlp:AttributeQuery>
<saml:Subject>
<samlp:AttributeQuery>
<saml:NameIdentifier...>
attribute-value...
</saml:NameIdentifier...>
</samlp:AttributeQuery>
</saml:Subject>
</saml:NameIdentifier>
where the surrrounding context may play a role to determine the
<saml:NameIdentifier..., attribute-value> pair.
Are these something that we need to worry about?