[Openid-specs-ab] Multipass Container Proposal

Tobias Looker tobias.looker at mattr.global
Fri Jul 31 04:24:25 UTC 2020


Hi David,

This is very interesting, I will take some time to review this closer
however a quick skim looks as though its intent is very similar to what we
have been working on with client bound assertions (
https://github.com/mattrglobal/oidc-client-bound-assertions-spec)

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker at mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Fri, Jul 31, 2020 at 2:40 PM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hello everyone!
>
> As alluded to at the end of the workshop call on Monday, I wanted to share
> a proposal towards the recent SIOP interest.
>
> The idea is to have a general mechanism to request credentials from an
> issuer and retrieve a single-use ‘container’ of credentials from the issuer
> which can be selectively disclosed. The format of credentials is purposely
> left out of scope, but key is provided with the container for parties to
> leverage for credential verification. We have already put some thought into
> some initially proposed credential types.
>
> The goal was to create a container and a request mechanism which would
> allow for the minimum amount of disclosure when used. Container
> verification does not mandate a global subject identifier or the use of
> DIDs, allowing these to instead be selectively disclosed as credentials. It
> is also meant to support privacy with respect to which parties credentials
> are disclosed with, up until the verifier and issuer start colluding.
> Finally, the process of retrieving a single-use container is detached from
> usage, allowing for them to be cached for disconnected/offline use.
>
> I hope this is useful to the group, and I welcome feedback! The current
> version is on https://github.com/dwaite/multipass , with the latest built
> version of mainline at
> https://dwaite.github.io/multipass/draft-waite-multipass-retrieval.html .
>
> -DW (David Waite)
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200731/621cd8e0/attachment.html>


More information about the Openid-specs-ab mailing list