Credentials & Contracts Manager
The Credentials and Contracts management app, is in some ways a component of the AgentDirectory. Another term that is used is OpenBadges which is presently implemented in a manner that is designed prodominetly for the education market, and I think that there are some complicated underlying reasons why that occurred; which I think would be unfair to go into... or perhaps it was because i think i might have been involved... idk. In anycase, i've put some more background notes at the bottom of this note; whilst highlighting that there are issues that are emotionally contentious for me.
Requirements.
When people form relationships with one-another they need to be defined via a credential. When people engage in work or other trade related activity, they need to define a contract; and these contracts should not be asymmetrically defined.
These requirements are primarily forfilled via the use of ontologies; and there is a bunch of ontological work that needs to be done in-order to produce FitForPurpose tooling that is able to be employed to generate credentials in a manner that is consistant with the ValuesCredentials and various other moral, technical, ethical and socioeconomic considerations at large. The preference at this stage appears to best consider how not to use DID technology where possible, in its current form. Decentralised identifiers were hoped to be usefully employed as a set of tooling that could be considered FitForPurpose however i have serious concerns that this is not what has happened, as although users are expected to be required to use the technological tooling via gov, etc.
The alternative for decentralised resources are sought to be supported (in a manner that is consistant with long-term designs) is to employ PermissiveCommonsTech methods as the means to manage the ontological resources. IF/WHEN DID technology or a variant of it (that may require a different name) is confidently able to be used in a manner that does not - by design - undermine the ValuesCredentials it'll be considered.
Application Requirements
Credentials are required to support creating relationships between agents. They govern the expected terms that are agreed between the parties for the period through which that agreement remains in place; changing the agreement will require the revocation and (optionally) issueance of a new credential. The credential contains the ontological references associated to the 'rules' that are defined about how the relationship is expected to be subject to terms - particularly ValuesCredentials (unsupported more broadly otherwise) and in-turn, save exceptional circumstances, the duties and responsibilities encumbant upon the parties for the duration in which that agreement remained in place; continues, beyond the time in which that agreement may have been terminated and/or modified. As the terms are defined using ontologies, they are both human and machine (ai) readable.
Other 'credentials' may relate to acknowledgements, or tickets or party invites, etc.
The Concept of Contracts has been seperated; even though, they're both kinda similar. The primary lens being with respect to the focus of producing TheWorkPlatform and in-turn produce support for the functional needs of that platform. Fundamentally, when people engage in a project, there's a set of expectations that are defined to bilaterally support the relationships between those involved and in-turn the expectations that are applied upon the thing, that is the subject of what people are working to develop.
These instruments in-turn produce the obligations, including statements about Currencies and how it is expected that people are renumerated for their time/effort; the conditions, structure, limitations, etc. These instruments do in-turn link to other credentials.
Finally also, Verifiable Claims!
Whilst noted VerifiableClaims&Credentials one of the most important usecases for these instruments related to the production of SafetyProtocols related infrastructure to extinguish the support that is otherwise part of StrategicHarms and CriminalActivity that is entirely connected to serious harms; yet, even though its often connected to work activities undertaken by persons funded by government; there's no proper means to seek lawful remedy, compensation, resolution (ie: the responsibility for the wrong-doer to address and fix the problems related to their wrong-doings); and in-turn also, consequences upon those who - irraspective of their employer - may well have knowingly engaged in wrongful behaviour for gainful purposes with the belief that there would be no negative consequences levied upon them personally - its just how they make money... When these sorts of behaviours associate with wrong-doings that seriously harm the lives of children in particular - i think that's really fucked-up.
So. The point of verifiable claims was also to provide crypographically enhanced HyperMediaContainers that could store as evidence, audio, video, images, structured data, unstructured data; and an array of metadata, for the express purpose of seeking to ensure the production of 'truth telling infrastructure' that is able to be used in a court of law. This is in-turn something that it is increasingly clear government is aligned with organised criminal professionals in the private sector, to seek to ensure does not exist. The reason why it has become so clear, is that government has in no uncertain terms stated clearly that they know it all, and have been doing it all already; meanwhile, they've been deploying derivatives of work that i've been involved in creating, without delivering the useful applications of those works as was intended when designing the technology - to address serious issues relating to PublicSectorWrongDoings and in-turn also CriminalActivity, StrategicHarms and other SocialAttackVectors generally otherwise.
SO, i do not see how they could possibly be both doing it all already; whilst knowing it all, then failing to deliver the tooling needed to protect people and simultaniously acting in a manner that demonstrated their commitmen to any of the ValuesCredentials which i might note; in its broadest form, a concept that they do not materially support.
As such, it is increasingly evident that it is of perhaps greater importance to ensure these systems are able to protect people from the consequences of wrong-doings that are firstly committed in an initial event; but may then more broadly become endemic as others throughout the public sector engage in PublicSectorWrongDoings in-order to seek to distort reality in a manner that they seek to benefit from by protecting wrong-doers from the consequences of wrong-doing; which is in-turn, enormously costly.
These tools and instruments are intended to support the use of the TimelineInterface alongside other tooling overtime, including but not limited to various functions that are part of how the webizen agent operates, to support SafetyProtocols for their owners.
BACKGROUND
From around 2012 onwards works led into W3C to produce Credentials, although there was work relating to the objective that i had been working on earlier; just not to the stage where I reached out to anyone involved in defining the standards for the web, which is something that i'd never thought i'd ever be involved in doing in my life...
anyhow.
W3C is about producing designs that are awarded royalty free licensing of the patent-pools held by W3C members - which is basically every Large entity in the tech-sector World-Wide. W3C is not about producing products, therefore the works are about desiging the requirements for a tool that can be employed for many different applications; which is in-turn a seperate process.
There was already WebID-TLS and seperately WebID-OIDC was later developed. Yet these instruments did not provide a means to support a 'verifiable claim' or a means to communicate a cryptographically enhanced document or package; that could be used as evidence. Within W3C these sorts of functional requirements fed into what was needed for the Web Payments related usecases; and therein, was initial work on Credentials. The work was originally being undertaken in connection with the Education Sector, which thereby denotes the relationship to OpenBadges but also, eventually, the Credentials CG was established and with that work came the development of 'verifiable claims', alongside 'decentralised IDentifiers'. Overtime others got involved, and the works were redefined in many ways; as some of the people involved sought to form a commercialisation capability for digital identity built upon the growth of these tools; the consequence has then become the development of what was renamed 'verifiable credentials' and in-turn also, whilst Decentralised IDentifiers still holds that name in some technical reports; there are alot of people who like to define them as Decentralised IDENTITY'; which, i think poorly of... some notes about it DIDsEval.
It is not what i seek to support in its current form; as a consequence of what i believe to understand, what i don't understand and the issues that are not adequately understood in the positive - as of yet. Some consideration is being made about how to employ DNS records to strip the registry function away from a centralised approach to a human centric related approach... but this is not considered to be a priority, yet, tests should be carried out if / when there's a clear - simple - opportunity to do so...