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>