[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Digital Identity and IContext open() method
|
So by 'provider' I was just referring to the extension that implements
the Namespace extension point...simply a provider for creating ID
instances of arbitrary type.
I understand. I'm just claiming that IdAS should not have to provide
code to create the tokens needed to authenticate to Contexts. It's the
consumer's responsibility for creating this token, and it's the
Context's responsibility to tell the user what it needs (via the
policy). If the consumer uses a Namespace ID extension, that's fine --
but that's code that lives on his side of the interface, not ours. (I'm
hoping someone else will jump in a agree or disagree with me on this.)
I have to admit I'm still a little confused by the current use of the
term 'provider' WRT the Higgins model. Given the recent discussions
it's not at all clear to me what the sequence of operations is for
creating/using an IContext with a real use case. Could someone point
me to example and/or junit test code that uses the API in current
expected/proscribed manner?
Let me give it a try:
(1) Consumer of IdAS service (aka User) needs to get a particular
Attribute value for a particular DigitalSubject, and he has the URI of a
Context that is likely to provide the required value.
(2) User contacts IdAS service and finds a ContextFactory that can
handle this URI.
(3) User asks the ContextFactory to create an IContext.
(4) User queries the Context's policy (IContext.getPolicy) to determine
what credentials are needed to open it.
(5) User calls IContext.open to authenticate to the Context and gain
access to its data.
(6) User searches for DigitalSubject (IContext.getSubjects) and
retrieves desired Attribute value (IDigitalSubject.getAttribute).
(7) User calls IContext.close to terminate use of the Context.
