| 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. What do you think about this format below? If you decode the string W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0= it yields: which was generated by var text = "["+login.hostname+","+login.formSubmitURL+","+login.httpRealm+"]" -Axel Hi Valery. See ##inline.
On 4/28/09 11:17 AM, "Valery Kokhan" <vkokhan@xxxxxxxxxxxxxx> wrote:
Hi Paul,
As far as I remember the main goals of making password cards fully
compatible with generic p-cards were standardization and
interoperability so we could use standard .crds format to store them
and to pass across different selectors.
## as much as possible, yes.
I've reviewed once again our design options. I agree that "Per role"
option is the best but if we use proposed set of required claim types
I do not see real way for this option to do both store all those
claims in .crds format and make user name and password claims be
indexed by three other claim types. In order to be able index UN & PW
we need to store some kind of hash table in .crds but how could we do
this?
## I’d suggest that in the persistent file format the value of the username claim, for example, would be an XML-structured value that encodes the multiple, rp-site-dependent values of username. This is hinted at here [1] with mentioned of “arrays” etc.
## If host_name + realm_name together can be used to identify the rp site (or app) then we’d need to store as the value of the username claim a set of N {username, host_name, realm_name} triples in the XML. And we’d do the same thing for the password claim value ---a set of N {password, host_name, realm_name) triples.
## If you design an XML syntax, please add it here [1] and we can all review it.
## [1] http://wiki.eclipse.org/Password_Cards#Architecture
If we a going to move forward with "Per role" design option I'd
suggest to use only two claim types for user name and password claim
values while host name, form submit URL and http realm should be
included/encoded in a query part of URL for both user name and
password claim types.
Thus, for any card for some particular role will contain two claim
types for each particular site log-on:
http://schemas.informationcard.net/@ics/username/2009-3?host_name=host_name&url="">
http://schemas.informationcard.net/@ics/password/2009-3?host_name=host_name&url="">
## What you propose above as a way to pass the parameters is not unreasonable, and in fact had been my original thinking based on Axel Nennker’s original suggestion to use “?” parameters from last year. Folks in the IMI TC do NOT think that this “?” is a good way forward as opposed to a much more comprehensive, general purpose solution that (as I understand it) involves passing full WS-SecurityPolicy expressions in the getDigitalIdentity() API call, as opposed to the limited subset that the <object> tag currently supports. However, this is all many moons away from being resolved. Since you need to do SOMETHING immediately, I’d go ahead and use the “?” approach and let’s keep an eye on this as things evolve at the ICF and within the OASIS IMI TC.
Of course if we move forward with this we will need to be able to
manage claim types dynamically but from my point it is the only way.
--
Thanks,
Valery
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
