...
Portability
...
must
...
be
...
included
...
as
...
part
...
of
...
a
...
thoroughgoing
...
review/rewrite
...
of
...
the
...
section
...
of
...
eduPerson
...
(200806)
...
on
...
"Identifier
...
Concepts:"
...
...
1)
...
uniqueness
...
2)
...
persistence
...
2a)
...
reassignable
...
3)
...
mutable
...
3a)
...
resynchable
...
4)
...
palatable
...
5)
...
opacity
...
6)
...
correlatable
...
7)
...
privacy
...
8)
...
portable
...
Many
...
of
...
these
...
properties
...
need
...
to
...
have
...
more
...
possible
...
values
...
than
...
True
...
or False.
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Beyond that, while a few (if any) are properties of the identifiers themselves, most are properties of the use of the identifiers in the context of many interacting systems (privacy being perhaps the best example of this). False. {builder-show title=The Problem with Glossaries} Beyond that, while a few (if any) are properties of the identifiers themselves, most are properties of the use of the identifiers in the context of many interacting systems (privacy being perhaps the best example of this). I observe that glossary exercises are doomed to failure if they are merely dictionary-style definitions. The useful activity is in building a model of interacting systems and components that support real-world processes, within which properties such as those above can be explained (insert obligatory reference toI observe that glossary exercises are doomed to failure if they are merely dictionary-style definitions. The useful activity is in building a model of interacting systems and components that support real-world processes, within which properties such as those above can be explained (insert obligatory reference to This is somewhat depressing as building a model is on the face of it more difficult than defining some terms (scope creep is inevitable) but at least it has a chance at success. Look at reassignment. It has to do with practices at the IdP, whether an identifier continues to apply to the same entity or can be used for a different one. The identifier stays the same, it's the mapping to the "real world entities" that might change. So the model needs to include those entities, the IdM system that maintains (or doesn't) the mapping, and the interest of the RP in the continuity of the mapping. These are the same components that are called out in the Assurance material.
"Bob" Morgan {builder-show}Morgan |
Here's
...
a
...
trial
...
run
...
with
...
further
...
revisions
...
(dependency
...
is
...
indicated
...
by
...
indentation)
...
University
...
of
...
Wisconsin-Madison
...
Name Identifier Properties | ePPN | UUID | PVI | ePTID |
|---|---|---|---|---|
– Scope | wisc.edu | wisc.edu | wisc.edu | wisc.edu |
| within scope | global | within scope | global |
– Reversable | reversible | reversible | reversible | reversible |
– Persistence | persistent | persistent | persistent | persistent |
– Transparency | transparent | opaque | opaque | opaque |
| palatable | no | palatable | no |
– Mutable | mutable on approved user request | mutable only in case of mistaken identity | mutable only in case of mistaken identity | mutable |
| potentially | no | potentially | no |
| resynchable | no | no | resynchable |
– Correlatable | correlatable | correlatable | correlatable | only within specific application group |
– Portable | no | potentially | no | no |
NOTE: Name identifiers are a threat to privacy to the extent that they are transparent, reversable, resynchable,
correlatable and portable