Re: what do we mean by "signal", was Re: CredWeb Plans, meeting tomorrow

On January 20, 2020 4:45:40 PM EST, Leonard Rosenthol <> wrote:
>> CredWeb is aiming at a social notion of trustworthiness
>Interesting.  While that might work for web sites/pages – it won’t be
>for the assets contained on those pages (or found elsewhere on the
>Is that direction locked in stone for CredWeb?   Would the group
>consider expanding its definition of “Credible” and “Web”?

We don't have a formally approved charter,  so nothing is locked in stone. 

Can you give me a concrete example of the kind of functionality you're looking for?  I'm not quite sure what it means for a digital asset to be trustworthy. 

What comes to mind for me is digital cameras attaching time and location and camera ID information to photos in a way that's potentially quite hard to forge (and hopefully also doesn't reveal private information). Is that the kind of thing you're talking about? 

     - Sandro

>Concerning VC – I think if you forget about the specifics, the idea
>that your claim/signal/whatever *must be* “integrity protected” is key.
>This is especially true if/when it is separate from the people (and
>their trust/reputations) involved.
>From: Sandro Hawke <>
>Date: Monday, January 20, 2020 at 3:44 PM
>To: Leonard Rosenthol <>, Greg Mcverry
>Cc: Credible Web CG <>
>Subject: what do we mean by "signal", was Re: CredWeb Plans, meeting
>Mostly we've just been using the email list for announcements, but in
>the interest of getting more discussion going, I'm going to offer a
>substantive reply, below.  Hopefully the Subject line above lets you
>know if you want to read this.
>On 1/20/20 2:32 PM, Leonard Rosenthol wrote:
>> that "signal" has a long history in credibility research as a
>"marker" to the consumer to indicate if a source is credible or not.
>So that sounds like an alternative term for what I have been calling a
>“claim” (based on the terminology from the Verifiable Claims (now
>Credentials) WG at the W3C -
> Yes?
>Does a “signal” use any sort of technology to ensure authenticity (eg.
>hashes or signatures)?  Or is that out of scope or TBD??
>I think the term "signal" is used somewhat loosely, a bit like
>"information".  Here's draft text from Credibility
>Our basic model is that an entity (human and/or machine) is attempting
>to make a credibility assessment — to predict whether something will
>mislead them or others — by carefully examining many different
>observable features of that thing and things connected with it, as well
>as information provided by various related or trusted sources.
>To simplify and unify this complex situation, with its many different
>roles, we model the situation as a set of observers, each using
>imperfect instruments to learn about the situation and then recording
>their observations using simple declarative statements agreed upon in
>advance. Because those statements are inputs to a credibility
>assessment process, we call them credibility signals.  (The term
>credibility indicators is sometimes also used.)
>That's just draft text, and I don't know that everyone agrees with it.
>It also intentionally glosses over several levels of meaning that could
>have more precise terms.  Some of these levels will speak more to
>different kinds of people than others (#2 uses TCP, #4 uses RDF). For
>example, consider:
>1. The age of an internet domain can related to its credibility. So we
>can talk about this being a signal, maybe called "age of domain". This
>kind of information, this "signal", is used informally in practice now,
>and perhaps in some automated systems. It's a signal that's moderately
>useful because it stops someone from trivially setting up hundreds of
>websites, but it's also not all that useful because (a) attackers can
>buy old domains on the aftermarket or buy them in advance and let them
>sit before using them, and (b) it could penalize legitimate sources. In
>this sense, a "signal" is general concept of a type of information.
>2. There are some protocols for finding out the age of a domain.  For
>instance, I can open a TCP connection to port 43 of
>, send "<CRLF>" and get back text that
>includes the line "   Creation Date: 1994-01-18T05:00:00Z". We might
>call this "credibility data", "signal instance data", or perhaps "an
>observation". Loosely, we could call this a signal, leaving implicit
>that it's a signal about
>3. Somewhere between these two, we might define the creation date of a
>domain as the isodate timestamp of the moment the domain registrar
>originally recorded as the creation of the domain, when it was most
>recently created. Or something like that. Trying to be precise. Call
>this a signal definition, maybe, or a signal specification. If we want
>interoperability between multiple systems producing and consuming
>credibility data, I think we need to get to this level. In practice,
>for age of domain, we'd want this to line up with the available data
>sources. No point in specifying something we can't have.
>4. Finally, there is some kind of standardized format for this data. In
>JSON, maybe it's something like
>  "domain": "",
>  "created": "1994-01-18T05:00:00Z"
>which might come out in Turtle as
>[] cred:domain ""; cred:created
>Alternatively, one might define the RDF mapping so we get something
>cred:domainCreated "1994-01-18T05:00:00Z"^^xsd:dateTimeStamp
>although to me that feels like bad modeling.
>I lean towards something like:
>[] cred:domain ""; cred:created
>   a cred:Observation, a cred:DomainAgeObservation.
>So, that last bit brings us back to sense 1.  I'm suggesting the object
>which connects a domain name and its creation time is a kind of
>observation, a domain name observation. We can also attach to it who
>did this observation, and when, and how. Then we can say "credibility
>signal" is a class of observations relevant to credibility assessments.
>The observations can then be encoded in data formats like Turtle, or
>CSV, or whatever.
>I haven't thought through exactly how the observations relate to
>Verifiable Credentials. VCs go much deeper into a narrower use case.
>There may also be some impedance mismatch with VC's crypto-centric view
>of the world. I'm reminded of the Knuth quote, "Beware of bugs in the
>above code; I have only proved it correct, not tried it." That is,
>crypto wont help if the institutions behind it are corrupt. CredWeb is
>aiming at a social notion of trustworthiness. (I'm by no means
>dismissing crypto, which is incredibly useful at fending off a whole
>range of threats. There are others it's not so useful against,
>Hoping this made things more clear, not less,
>     -- Sandro
>From: Greg Mcverry
>Date: Monday, January 20, 2020 at 2:08 PM
>To: Leonard Rosenthol <><>
>Cc: Sandro Hawke <><>, Credible Web CG
>Subject: Re: CredWeb Plans, meeting tomorrow
>I believe, though class schedules kept me from meetings last semester
>and I am not a developer, that "signal" has a long history in
>credibility research as a "marker" to the consumer to indicate if a
>source is credible or not.
>So the RDF would be a bit of machine readable data as a vocabulary of
>of traditional human readable and disagreeable signals of credibility.
>For example you may have a currency "signal" that equates to an RDF
>vocabulary for publication date.
>Please others correct any misconceptions I may have.
>Should be there tomorrow, first day of semester, never know what random
>meetings pop up.
>On Mon, Jan 20, 2020 at 12:32 PM Leonard Rosenthol
><<>> wrote:
>I apologize in advance if this is explained elsewhere – but I don’t
>understand the difference you are making between a “signal” and the
>“data format” that an API would use (or might be embedded in an asset).
>I realize that I am coming at this from the side of assets (image,
>audio, video, documents) as opposed to web pages – but to me they are
>one and the same.
>From: Sandro Hawke <<>>
>Date: Monday, January 20, 2020 at 11:31 AM
>To: Credible Web CG
>Subject: CredWeb Plans, meeting tomorrow
>Resent-Date: Monday, January 20, 2020 at 11:30 AM
>Hey folks,
>It's a new year, and we've had some quiet weeks.  I'm trying to settle
>on some next steps for the group. Here's what I'm thinking:
>1. Let's not try to update the report right now. Let's just convert it
>to a "final report", to make it properly archival, with a clear note
>that it was written in 2018. Maybe a short name like "Credibility Tech
>If there's sufficient interest in a revision or new reports that are
>more focused later, that's fine, but I don't think it's the best use of
>group time right now.
>2. Instead of Credibility
>trying to include everything about signals while also highlighting the
>good stuff, let's split it into three different resources:
>* Credibility APIs, a technical guide for how computers should talk to
>other computers to exchange credibility data. Included data formats,
>protocols, RESTful APIs, browser APIs, etc. Not a spec for any of
>these, but an overview of options that are specified elsewhere. I'm
>thinking we can publish a small draft and start to gather input.
>* A Credibility Data Exchange, a website for exploring all the signal
>definitions and signal instance data people are willing to make public,
>with clear attribution back to the sources and no endorsement from us.
>I've made a few prototypes over the years (like
>but none I was happy with, yet. Maybe this should just be my thing, not
>the group's; that's topic for discussion. (It might help if someone
>wanted to fund this.)
>* Endorsed Credibility Signals.  This would be a relatively small
>document, describing 5-20 signals where we have consensus within the
>group that they are pretty good. I'd expect it to change over time with
>new data. The RDF schema for these signals would be published on
>It would intentionally be kept small enough to be manageable, unlike
>the Exchange as past "Signals" drafts. I think some of the NewsQ
>are good options here, and there are also some that are doable by hand
>So, agenda for tomorrow is to talk about this plan, and if there's
>time, talk about the actual signals we might be ready to endorse.
>If you can't make it to the meeting and have thoughts on all this,
>email could be helpful.
>Meeting, as usual:
>January 2020 1pm
>     -- Sandro
>J. Gregory McVerry, PhD
>Assistant Professor
>Southern Connecticut State University
>twitter: jgmac1106

Received on Monday, 20 January 2020 23:30:29 UTC