RE: [higgins-dev] Updating Password with IdAS

[David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>]

Jim, 

Thanks for the response.  Some
further comments and responses to your questions.  

... snip...

>>-- Are the CPs required to provide generated IAuthNAttributesMaterials
when newMaterials is null and oldMaterials is specified?  Not all
registries have that capability to generate credentials. What exception
should the CP throw if it can not generate materials? NotImplementedException
does not seem to fit quite right.   
>I agree, an exception should be expected when the
Context Provider or the Context's policy prevents this.  Should we
add a generic OperationNotPermittedException or something more specific
like UnableToGenerateAuthNMaterialsException?

Because the sematics of null newMaterials
and oldMaterials has the meaning of "generate materials", then
a more generic exception would be fine, because the application should
know the meaning. I am hung up on the word "Permitted". It makes
me think authorization. I would suggest OperationNotImplemented

>>-- How can I set the metadata of the attribute that will ultimately
hold the IAuthNAttributesMaterials for the specific IDigitalSubject? When
I reset a password, I may want to pre-expire a password, so that it must
be changed on first use. 
>There's no requirement that the authentication identity
be a digital subject in the context.  

I agree with this statement for "open".
 A context can accept a connection by an identity that is defined
outside of the context.  But I have difficiculty understanding this
for "update".  What other object in the Context can be updated
with the new materials if not a Digital Subject?  Can the Context
have an internal set of identities that are not represented as DigitalSubjects?
 Can you give me an example of this?   

>Further, there's no requirement that any/all of the
other authentication materials (including a password) be represented by
an attribute (even when the authentication identity is a digital subject
in the context).  I think that if there are capabilities like you
mention above (pre-expire a password), then the authentication materials
object needs to be specified in such a way as to allow that data to be
conveyed.

How would authentication materials be
persisted and retrieved?  In order to query metadata about the authn
material (last changed, expiration, policy), management apps would need
to be able to get oldMaterials from a DigitalSubject from attributes with
the type of IAuthNAttributesMaterials.   Also, there would need to
be a way to call updateAuthNMaterials so that the metadata can be updated,
without updating or nulling out the actual authn materials.  

>>-- How does the application get the password strength policy before
attempting to call updateAuthNMaterials or after a call to updateAuthNMaterials
fails?   Have you considered a defined exception for a failure to
update due to a policy violation? 
>We don't yet have any kind of capabilities or policy
discovery methods that would allow this.  I agree we need those kinds
of methods, and can add them separately from this one.  In terms of
the exception, I agree something would be useful but I'm not sure how general
(PolicyException) or specific (PasswordStrengthException) to go.

I always envisioned the password strength
policy as metadata that could be queried from the password attribute of
a DigitalSubject. The policy for each DigitalSubject and each password
attribute could be different. 

>>-- I am OK updateAuthNMaterials at the level of the IContext, but
apps will still need to be able to query the value and metadata of AuthNMaterials
attributes at the IDigitalSubject level. 
>This would only be possible when the authn identity
is also a digital subject.  If that is the case, then the application
would need to know what those attributes are.
 
This splits the interface for updating
across IContext and IDigitalSubject, where the materials are updated at
the IContext level, and the metadata about the materials is accesses on
the IDigitalSubject.

>>Apps need to be able to query
meta-data (e.g. expiration date, last changed date, password history, password
policy, etc.).  If supported by the repository, the ability to read
the hashed or encrypted value is also useful for migrating or exporting
digital subjects to other registries, while preserving the authn materials.

>Would you want to be able to do this regardless of
whether or not the authentication identity is represented as a digital
subject?

I am having a hard time understanding
the use case where the identity is not represented as a DigitalSubject
in some Context and can have a managed set of authn materials. I think
my answer is yes, but I do not understand the non-DS use case where authn
materials can be updated.

>>-- This comment is nit: Using the convention of specifying a value
for oldMaterials and null newMaterials to cause IAuthNAttributesMaterials
to be generated seems a little awkward to me, because there are no old
materials in use.  
> I guess I'm assuming
that authentication materials may (even typically) consist of two kinds
of data: non-secret data which is used more to specify the authentication
identity, and secret data which is used to verify that identity.  In
cases where this is true (such as authentication materials which consist
of username and password), the oldMaterials may be partially populated
(with the identity data -- like username) when the caller doesn't need
to specify the secret data for whatever reason.
 
>>New materials may need to be
passed in as part of the oldMaterials object, in order for the CP to be
able to generate the new IAuthNAttributesMaterials. The example I can think
of is passing in a certificate request as oldMaterials to cause the CP
to generate, store, and return a certificate.  This maybe an invalid
use case. 
>Hmm, I can see there being a case like that (caller
needs to provide a little bit of data -- like a seed -- such that the generated
materials may be produced).  Well, do we want to provide for that
now, or push that off until we refactor IContet.open (as well as this method)?

This still works using oldMaterials,
if the oldMaterials object can contain new data.  Like I said, a nit
about semantics. 

However, this brings up the assumption
that the interface for authenticating to a Context should be the same or
similar to the interface for managing the authn materials. They are not
related and have different requirements.  A JAAS like interface for
open makes perfect sense. However, JAAS Subject does not contain the capabilities
for managing the life cycle of authn materials used for credentials.  
I think you actually need other APIs, like verifyAuthNMaterials in order
to support creating a JAAS subject.  

From a management perspective, my assumption
is that IdAS Digital Subject is the interface I would use to manage the
authn materials (passwords, keys, certificates, tokens. etc.) for a user,
application, or device.  If the authentication identity is managed
outside of IdAS, then I would be using some other API to managed the authn
materials.  

Thanks for your consideration here, 

David