I think that there are several ways to implement password
cards.
1) extend p-card with new non-standard
claims
2) define m-card with "special" issuer
Although I think that p-cards with new non-standard claims
make sense and should be blessed by the ICF and OASIS IMI TC as valid, I think
that password cards are not the best reason for them.
For password cards I prefer a managed card with a special
issuer. This could be either something like what I have choosen "urn:openinfocard:storage:component"
(we should define something "standard" for this) or - if you want to stick
closer to the standard - a http://localhost:32007/issue url. Or you
could have this issuer in the cloud...
<TokenServiceList>
<TokenService>
<wsa:EndpointReference>
<wsa:Address>http://localhost:32007/issue</wsa:Address>
<wsa:Metadata>
<wsx:Metadata>
<wsx:MetadataSection>
<wsx:MetadataReference>
<wsa:Address>http://localhost:32007/mex</wsa:Address>
</wsx:MetadataReference>
</wsx:MetadataSection>
</wsx:Metadata>
</wsa:Metadata>
</wsa:EndpointReference>
<UserCredential>
<DisplayCredentialHint>internal</DisplayCredentialHint>
<UsernamePasswordCredential>
<Username>internal</Username>
</UsernamePasswordCredential>
</UserCredential>
</TokenService>
</TokenServiceList>
My current format does not have a ServiceEndpointList and
no metadata-endpoint. but this is not necessary for a special build-in
issuer.
I think that it is possible to build password cards with a
format that is 100% conformant to ISIP.
I believe that a selector that is outside the browser;
either in the local operating system or in the cloud - should go this 100%
way.
A selector like openinfocard could/should go another way.
openinfocard as a Firefox extension could/should use the browsers password-store
directly. The login credentials would be presented as cards but the internal
format is not changed. And the Firefox login manager is protected by the Firefox
masterpassword.
If you have a local or remote issuer for these cards then
that issuer should be protected by some credential.
-Axel
I added some schema definition to the card below and
Netbeans tells me that the format is valid with resp
to identity.xsd
</RoamingStore>
Axel, are you thinking of this as a normal m-card or crating a
custom personal STS for the issuer?
If the URI is a one way hash then you could also include password manager
secret into the string to be hashed.
The user could give the "password secret" to approved password managers.
That prevents accidental disclosure. A third party can't ask for
a card for a site without knowing the secret.
The question would be where the actual site name is stored in
the card for display.
Perhaps the password manager could include
the un-encoded information in the card when it issues it.
Who or what do you see issuing the card?
John B.
|