In W3C specs, Verifiable Presentations are used to combine multiple Verifiable Credentials, bind it to a single transaction via nonce, and adds a signature of the sender.
In Sovrin, a (Blinded) Link Secret is used to combine multiple Verifiable Credentials and bind it to a holder.
On Sovrin related sites there is little about "Verifiable Presentation" and on W3c there is little about Link secrets.
What is the relation between the two, how are they used and how do they differ?
Related
According to definition of ERC1400 here
https://github.com/ethereum/eips/issues/1411
it has the ERC-1643: Document Management Standard.
now my question is, How do these documents/files stored?
are they stored in the contract as a hash?
are they uploaded somewhere, if so, where?
Also, while were at it, were can I find sample codes/resources for various ERC standards as well, I dont seem to find any sample codes on theses ERC standards everywhere :(
Note that both standard proposals (ERC-1400 and ERC-1643) are currently (April 2021) still in the draft phase (for over 2 years since they were created). Meaning they haven't been approved by the core team, and not many developers are going to follow an unapproved standard (or publish code samples).
How do these documents/files stored?
The draft of ERC-1643 only defines an interface (function names, argument datatypes, ...), not the actual implementation (how to store the data - that's up to each developer to implement to their use case).
The string _uri that the standard defines as one of the arguments, can be:
IPFS (decentralized storage, my guess is that this is going to be the most common use case)
off-chain file sharing service such as Google Drive
or it can even be an URL accessible only on some private networks
basically any valid URI (so even ftp://, skype:// or tel:// link)
Is there's a way to apply policies to specific groups of operations in Azure APIM?
AFAIK I can only apply policies to the following scopes:
global
API
operation
For my scenario I can't have some of the policies at the API (or global) scope, because some of them are not applicable to certain operations e.g. most API operations are protected by OAuth, but there's a couple of unprotected operations, so I can't put validate-jwt policy at the API scope. It would be nice if I didn't have to replicate the same policies for multiple individual operations.
FYI I tried adding tags to the Open API specification (which I used for the creation of the API), but I couldn't see a way to apply policies to these...
There is no way to do this yet, but a feature request exists which could help. You could up vote this for it gain more traction.
If applicable, one option would be to remove the <base /> tag for the operation, preventing it from inheriting policies from higher scopes (API, Product (if present), and Global).
I have created a chatbot using Snatchbot for the purpose of a quiz. I have been asked to create a dynamic decision tree structure for the chatbot which must be displayed on the web page, i.e. everytime the user answers a question, a branch on the tree must be created according the user's response. Is there anyway to do this? Is it possible to generate the JSON for the structure of the chatbot rather than the JSON for previous conversations? Would any other platform such as dialogflow be more suitable?
I am also using SnatchBot, you will need to use the NLP section to create all your samples and train your Data, then you could add global connections, Giving the possibility to direct the bot to the needed subject at any point of the conversation.
The value of this tool is that it allows the user to immediately (and at any point in the conversation) direct the bot to a particular subject.
Technical perspective, I have some recommendations for you:
https://jorin.me/chatbots.pdf (Development and Applications)
https://www.researchgate.net/publication/325607065_Implementation_of_a_Chat_Bot_System_using_AI_and_NLP (Implementation Using AI And NLP)
Strategy perspective, here are the crucial 6 different main criteria for enterprise chatbot implementation success:
Defining clear audience profiles of the project
Identifying clear goal for the project
Defining clear Dialog-flow Key Intents Related
Platform’s Customer Experience SWOT assessment Forming coherent teams
Testing and involving the audience from early on in the validation of
the project
Implementing feedback analytics to be used as basis for
continuous improvement
(Source: http://athenka.com)
I am looking for feedback on a certain directory structure for an application. I realize that this does not follow the classical stack overflow format where there is such a thing as "a correct answer", though think it is interesting nonetheless. To provide meaningful feedback, some context first needs to be understood, so please bear with me.
--
Two colleagues of mine and I have created an application that uses the Clean Architecture. HTTP requests to routes get turned into request models, which gets handed to use cases, which then spit out a response model that gets handed to a presenter.
The code is fully open source and can be found on GitHub. We also have some docs describing what the main directories are about.
We are thinking about reorganizing our code and would like to get feedback on what we've come up with so far. Primarily amongst the reasons for this reorganization are:
Right now we do not have a nice place to put things that are not part of our domain, yet somehow bind to it. For instance authorization code, which knows about donation ids (with authorization not being part of the core domain, while donation ids are).
It's nice to group cohesive things together. Our Donation code is cohesive and our Membership Application code is cohesive, while both don't depend on each other. This is closely related to the notion of Bounded Contexts in Domain Driven Design. Right now these contexts are not explicitly visible in our code, so it is easy to make them dependent on each other, especially when you are not familiar with the domain.
These are the contexts we have identified so far. This is a preliminary list and just to give you an idea, and not the part I want feedback on.
Donation
Membership
Form support stuff (validation of email, generation of IBAN, etc)
The part I want feedback on is the directory structure we think of switching to:
src/
Context_1/
DataAccess/
Domain/
Model/
Repositories/
UseCases/
Validation/
Presentation/
Authorization/
Context_2/
Factories/
Infrastructure/
tests/
Context_1/
Unit/
Integration/
EdgeToEdge/
System/
TestDoubles/
Context_2/
The Authorization/ folder directly inside of the context would provide a home for our currently oddly placed authorization code in Infrastructure. Other code not part of our domain, yet binding to it, can go directly into the context folder, and gets its own folder if there is a cohesive/related bunch of stuff amongst it, such as authorization.
I'm happy to provide additional information you need to provide useful feedback.
Right now we do not have a nice place to put things that are not part of our domain, yet somehow bind to it.
Right now these contexts are not explicitly visible in our code, so it is easy to make them dependent on each other, especially when you are not familiar with the domain.
There are both technical and non-technical ways to address this issue:
You can enforce stricter separation through class libraries. It is more obvious you are taking a dependency on something if you have to import a dll / reference another project. It will also prevent circular dependencies.
Code reviews / discipline is a non-technical way to handle it.
I've been using Hexagonal Architecture with DDD where the domain is in the middle. Other concerns such as repositories are represented by interfaces. Your adapters then take a reference to the domain, but never in the other direction. So you might have an IRepository in your domain, but your WhateverDatabaseRepository sits in it's own project. It is then the responsibility of the application services / command handlers to co-ordinate your use cases and load the adapters. This is also where you would apply cross-cutting concerns such as authorization.
I'd recommend watching Greg Young videos (try this one) and reading Vaughn Vernon's IDDD as it goes into how to structure applications and deals with questions like yours. (sorry that my answer is basically watch a 6hr video and read a 600+ page book, but they both really helped clarify some of the more "wooly" aspects of DDD for me)
As an example, see https://github.com/gregoryyoung/m-r/blob/master/SimpleCQRS/CommandHandlers.cs
Maybe I'm confusing things or over-complicating them, but I'm struggling to develop a RESTful API that supports both HTML and JSON content types. Take for example a simple user management feature. I would expect to have an API that looks like this:
GET /users: lists all users
GET /users/{id}: views a single user
POST /users: creates a new user
A programmatic client posting to /users with a JSON payload would expect a 201 Created response with a Location header specifying the URL to the newly created user, e.g. /users/1. However, a person creating a user through his web browser would post to the same URL with a form-encoded payload and would expect to be redirected to the user list page, requiring the API to return a 302/303 redirect with a Location header of /users.
From a purely conceptual point of view, I find it surprising that an API would react differently based on the submitted content type, and wonder if this is bad design. Then again, maybe it's a mistake to consider the programmatic API and the web-centric API to be the same API and one shouldn't worry about such concerns and worry more about providing a good experience to the different clients.
What do you think?
You've stumbled upon two separate issues.
One, the typical web browser is a pretty lousy REST client.
Two, web application APIs are not necessarily REST APIs (see #1).
And thus, your conundrum of trying to serve two masters.
Arguably representation has little to do with application semantics when it comes to details such as workflow, particularly if you have equally rich media types (vs a constrained media type such as an image, or something else).
So, in those terms, it's really not appropriate to have the application behave differently given similar media types.
On the other hand, media type IS Yet Another aspect of the request which can influence operation on the back end. You could, for example be requesting an elided "lite" data type that may well not offer links to other parts of the api that a richer media type would, or your authorization level is a factor on what data you can view, as well as what other relations are available, or even what media types are supported at all.
So it's fair that every aspect of the request payload can have impact on the particular semantics and effect of any particular request to the server. In that case, you're scenario is not really off the mark.
In the end, it's down to documentation to clarify your intent as an API designer.