Hi all,
I’ve been
promising this for awhile… one of the
use cases that we’ve had multiple
clients consider implementing via SPML
is for forgotten password reset and/or
recovery. Its an example of a use case
where we can add some “higher level”
capability to SPML so that it supports
the identity-management operations
that many applications provide,
instead of just lower level atomic
operations.
The existing set
and resetPassword operations can be
extended to cover forgotten password
reset/recovery by adding elements for
challenge/response questions and
answers, and we can also add an
operation for querying for challenge
questions for a given PSOID.
Some hacked up
non-normative examples:
<resetPasswordRequest
requestID=”135”>
<psoID
ID=”rsand”/>
<challenge>
<question>What was the color of
your first car</question>
<answer>black</answer>
</challenge>
</resetPasswordRequest>
Of course there
could be multiple challenge elements.
The process of
challenging for a password reset often
requires statefulness over two or more
requests, so a generic token element
can be used to maintain state. It can
also be used for example by captcha
mechanism if the PSP wishes to enforce
such a mechanism there (as opposed to
just leaving it up to the
application). A flow could go
something like:
1) Request
for pwd reset challenge
<resetPasswordRequest
requestID=”135”>
<psoID
ID=”rsand”/>
<challenge/>
</resetPasswordRequest>
2) Response
with challenge and token
<resetPasswordResponse
requestID=”135”>
<token>xyzH1</token>
<challenge>
<question>What was the color of
your first car</question>
</challenge>
</resetPasswordResponse
>
3) Request
for pwd reset with challenge answers
and token
<resetPasswordRequest
requestID=”136”>
<psoID
ID=”rsand”/>
<token>xyzH1</token>
<challenge>
<question>What was the color of
your first car</question>
<answer>black</answer>
</challenge>
</resetPasswordRequest>
There are a lot
of ways to express the above with
different semantics – I just made
those up as ideas. The point is that
its flexible and still allows the PSP
to determine what the challenge system
is that it supports. For example some
clients may have “buckets” of
questions where the user must select 1
question of out 5 from each of 3
buckets – I can see adding an optional
“challengeid” attribute of the
challenge element to enable the
systems to perform multiple challenges
in the same transaction for this.
The existing
(re)setPassword functionality allows
for the end user changing their own
password by supplying the old
password. We could also add an element
or perhaps an attribute to the request
element that specifies what type of
identity is making the request – is it
an administrator or is it the end
user? But also the notion of request
metadata, which is a separate topic
altogether, could meet that need.
Anyway look
forward to your thoughts and
comments. But this in general is the
kind of thing I want to add to SPML –
elements that are specific to higher
level IDM functions like self
registration, enable/disable of
accounts, self-service request access
to a role, etc.
Thoughts?
Richard
Sand | CEO
239 Kings
Highway East | Haddonfield | New
Jersey 08033 | USA
Mobile: +1 267 984 3651| Office:
+1 856 795 1722| Fax:
+1 856 795 1733
<image001.jpg>