Hello Sam, Josh
> 1) request default identity
> 2) Indicate whether an authentication was successful or failed. Note
> that sometimes the GSS library will not know, so we won't be able to
> tell you.
I'm working on these two points as we speak.
> 3) We need to update the identity provisioning design page's identity
> selection algorithm to cover the error cases.
I will add the steps and ask for feedback once I'm finished.
> Search by service only has been and continues to be the primary use
> case.
>
> In response to questions you raised:
>
> 1) We don't care how you store the multiple credentials. I'm not
> familiar with the desktop file format you propose. We do care that
> whatever you choose be available on Windows an Unix. We do care that
> your code use an abstract interface that is not specific to the file
> format. That is, the identity store should be isolated to one object and
> only that object should care about the details of the file format. Later
> we should be able to substitute sqllite, Windows registry, Gnome
> keyring, Mac keychain or whatever we like and only change that one
> object and none of the rest of the code. I realize this is
> obvious/basic, but it's important.
Just to clarify, GKeyFiles are exactly the same as the old .ini format,
so from that POV Windows support and support from other platforms is
wide spread. In our case it has the advantage that we don't have to add
any dependencies as GLib has this parser built-in. (Note that adding
dependencies to a cross platform app can be quite annoying).
> If Josh is OK, I propose to defer encrypting the passwords beyond this
> phase. It's messy because you really want to integrate with Gnome
> Keyring and the Windows platform features for this in order to get
> something approaching single-sign-on.
Agreed. Sounds sensible.
> Regarding what a trust anchor is. I believe my mail to the list
> yesterday mostly covers this. It's something that is an asserted point
> of local trust. In the case of libeap, it's either a set of CA
> certificates, or the hash of an end-entity server certificate.
>
Just to clarify, does a trust anchor belong to the ID Card info? My
understanding is that all that an id card needed was a certificate
string. Is there a
> At this point I think we're waiting for usability feedback on how to
> handle the trust anchors and to conclude negotiations on what we're
> doing about enterprise/web identity work flows. Especially if there are
> issues your engineers do not understand about the trust anchors, we
> should have a jabber chat or call ASAP.
>
> Several mails were sent to moonshot-community regarding the UI
> yesterday.
>
> Thanks for the updates!
|