# Rebase ## Meeting 2022.03.25 Eric: Have the user load their contextualized information connected to their wallet. Wayne: Must-haves. Orie: Vision -> Work Mode -> Must Haves. How are DIDs and VCs used to discover how identifiers are related to each other. Portable reputation. Oliver: Data models, binding cryptographically and other means the accounts. Dan: Agree, verify bindings across identifiers. Community Group Charter: https://docs.google.com/document/d/1sjzWsa33J6kSBH_X0CxI9DwYniwCTPG1rCJDFJz3SaQ/edit# ### Notes from Oliver wyc: agenda topics: wants to agree what are the must haves, what are the nice to haves, twitter, github, dns are must haves then talk about what we need to define per each must have, e.g., verification method (evidence) type joel: 2 layers: - naming, ens/dns - tieing to DID and where to store that inforomation - how to format verifiable credentials orie: - high level vision thing - descirbing how DIDs and VCs are used to discover how identifiers are related to each other, bitcoin, email, github, twitter etc. - how are they related to each other and how DIDs and VCs can help with this. wyc: - forward compatibility with something like deco since this is going to change everything. orie: - we need to agree shared vision, and work mode - basic amount of work mode skill is needed joel: is the goal to come together to have a standard way and example implementation create proof to create a web2 account with a DID danial: agreed eric: we should with this group but then we can bring in more companies but if we all go a separate ways, that would be not great we should all agree that all DID, web3 wallets, dApps validate someones profile and it should be a universal way to sign up. orie: there might be a subset of it that there might be ppl that might do it in a different way, to succeed, at being the best, wants to meet in a recurring manner. eric: do you really want to part of this joel? and want to join a bigger colelctive and do the same thing? joel: we have built a service with twitter, github but it is live, but not raelly in production. we didn’t have a lot of time to focus on it. this effort seems great because the ppl fit. would be good to have a place where we have a place wyc: we also have such a service similar to joe, similar interest. i have chartered a whole charter for rebase for a CCG at W3C orie: alternative is existing WG and apply to both to DIF and W3C CCG. alternative approach and create a github org out, draft stuff, don’t deal with other groups but we you plan some artifacts to go to some standards group. if you want to get bigger guys to participate. eip is more permissive, ccg is less permissive since lawers need to come in place ori: in order to be successful, it has to be large players with significant brands, contributed to its development eric: definition of that brands is important, no need for having goolge, amazon orie: what is success in 5 years from now? - twitter, kraken, square, meta using it 5 years from now are using rebase credentials to link what is failure? - it is a draft in a community group maintained by a bunch of startups wyc: is it seriously considered specifications that the FTC would consider when it drafts policies for big tech giants eric: agree initial set of companies are web3 wallets, dapps target market should be both, web3 and DIF ppl orie: web3 and social networks (web2) joel: what is the use case for applications actually verifying these proofs? wyc: use case doc orie: similar to verified email, so it would be good to have a verified twitter account or social media account faster than traiditional approach wyc: 1. 2. wyc: start with a github organization defer to decision where to home it we consider, w3c, dif, casa, ietf etc. but no decision today and meet bi-weekly eric: question to wyc and joel? connecting proofs together is one thing, discoverability is another thing and is needed? and joel has done some work on it today orie: let’s defer discovery conversation until we have some credentials dan: joel: definitely a worthwhile convo how to discover things but there too many aspects of that, there are so many types of use cases, let’s focus on structure. wyc: discoverability might be different from use case to use case instatiating the user’s context based on differnt stuff, e.g., after sign-in with ethereum let’s focus on data models and verification first orie: work mode is rebase.xyz, rebase.org is in DIF already we should fix branding we need a github org for top-level branding to get ppl to start organizing rebase.xyz is the external facing brand wyc: rebase.xyz fine eric: bought the domain, also fine orie: fix github org, rebase.xyz we should get a marketing website for rebase.xyz we can align specs underneath that not under DIF, just extract out of DIF no point in leaving it in DIF if there is no contributions wyc: most imoprtant things until next meeting: - updated vision - meeting time on the calendar - mocks for a website for rebase.xyz orie: - cannot help with no marketing - cannot help with specific schemas, but help refining them - i will help with spec wyc: - can you check existing schemas that are in the repo @joel? - what are relevant verification flows to you in your systems? - i will help with marketing - continue discussion on existing schemas and load vision in a PR eric: - will send out meeting invite for next meeting orie: - need also figure out eidtor chair roles