I can only find and download OSGi Specs(e.g. core-spec, enterprise-spec) from its website. What about so-called OSGi RFCs? Are they publicly accessable, and how related to the Specs? Thanks!
From this osgi.org page:
Each Expert Group works on items defined in documents known as Requests for Proposals (RFPs), which set the requirements for the technical development.
RFPs may be created by anyone but are always reviewed by the Requirements Committee to ensure they meet real-world needs and complement the larger objectives of the OSGi Alliance.
Assuming the RFP is accepted, the relevant Expert Group develops Requests for Comments (RFCs), which define the technical solution to the RFP.
The Expert Group also develops Reference Implementations and Test Cases to support the RFC where this is appropriate.
The Member Area of the OSGi web site contains much more information and detail on specific activities, including drafts and final versions of RFPs and RFCs, final but pre-release versions of specifications and other technical documents, minutes, schedules and calendars of Expert Group meetings, and other important information. This information is only available to members.
So only the members can access those RFCs.
Regarding "draft specifications":
From time to time the expert groups of the OSGi Alliance publish some draft RFCs under a special license (the Distribution and Feedback License) for a public review in order to receive comments from non-OSGi members and other organisations.
The download page to access these draft specs is http://www.osgi.org/Specifications/Drafts .
To keep the RFCs non-public was a decision to protect the IPR as well as to keep the resulting specifications as unconfusing as possible. Sometimes one or more RFCs are combined into one specification, sometimes an RFC amends an existing spec. The RFCs are basically work-in-progress.
There are some RFCs the OSGi Alliance decided to publish. Those are the ones you can access. One example is RFC 112 Bundle Repository. This is a stand-alone spec, which is complete in itself.
Related
What technical detail should programmers consider while developing their own oAuth service?
Have been trying to find out guidelines, but found most of the oAuth related articles discuss as a consumer point of view (i.e. how to consume others service). I want to design my own oAuth system with my authorization service and resource service. What technical detail should I follow?
You probably have read the RFCs but just in case you haven't, they're the place you want to start:
oAuth 2.0 "core" (RFCs 6749 and 6750)
Proof Key for Code Exchange (PKCE) (RFC 7636)
The best 'packaged' guidance for oAuth implementers (client or otherwise) is available via IETF Best Current Practices (BCPs). Most people know about IETF RFCs and (confusingly) BCPs are published as RFCs with a RFC number. Despite that, they're best practices and not formal specifications:
The BCP process is similar to that for proposed standards. The BCP is
submitted to the IESG for review, and the existing review process
applies, including a "last call" on the IETF announcement mailing
list. However, once the IESG has approved the document, the process
ends and the document is published. The resulting document is viewed as having the
technical approval of the IETF, but it is not, and cannot become an official Internet Standard.
BCPs you want to review:
oAuth security (up to date as of this writing)
oAuth for browser-based apps (up to date as of this writing).
oAuth for native apps (published in 2017 as an update to "core" oAuth 2.0 RFC, still a good read)
JSON Web Tokens for oAuth (up to date)
These documents are framed in threat model terms - they cover attacks (or "security considerations" as a diluted format) and countermeasures. You might be looking for a more straightforward building blocks type of a roadmap and perhaps there should be one as an educational tool. Real-world oAuth implementations must be developed with a prima facie evidence of a threat model.
As one samurai said: ...swordsmanship untested in battle is like the art of swimming mastered on land.
I would also be interested to hear why you want to develop your own auth solution.
But putting that aside, there is an open source project that does exactly what you ask - Identity Server. You can check out their source code or fork it and build something on top of it.
Also, please check "identigral" answer on various docs.
Does anybody know what is Group versioning in REST API?
I found the link below where it explains it, but i don't understand how to use it.
I am looking for:
How to configure group version across multiple endpoints ?
Can someone provide practical example of it ?
Github Microsoft API guidelines
Despite the vernacular, Group versioning is really nothing more than versioning by date. Most, if not all, Azure services version this way. You can choose whether you want to version by number or date - the two most common formats. Versioning by Group (e.g. date) is convenient for services. You know exactly when things were released. It can be difficult to track when a numeric version was deployed over time. Whether you map the group to some internal value is up to you, but I would claim it doesn't bring you anything but complexity and confusion. If you use a date for your version number, embrace it through and through.
The guidelines somewhat imply that you can have varying minor versions mapping to a single group (e.g. date); that could be dangerous. It's generally assumed that a minor version is backward compatible; however, a service should never assume that this is true. A service has no control over a client and their ability to handle even additive content (e.g. tolerant reader). The only type of versioning behind a group that should ever be done is patching, which has no visible wire protocol differences. You'll have to decide if it's worth mapping patch versions to groups/dates internally.
Whether you choose to version by number, date, or even both, is up to you. ASP.NET API Versioning is one such realization of these guidelines. It also includes support for a status (ex: Beta), which no longer appears in the formal REST guidelines. The wiki contains in-depth details.
I hope that helps.
PSD2, The Payment Services Directive of the EU.
Financial institutions in the EU need to be PSD2 compliant, and there's a bunch of vendors claiming PSD2 compliancy. PSD2 is supposed to be a uniform EU-wide standard, and there's a million whitepapers, video blogs, impact estimates, high level overviews, but no technical specification.
Nothing saying really what message needs to be sent where and then happens what. The closest thing I found is this but even there there's no reference, nothing to imply what exact technical spec they followed.
Does anybody know where to get the official PSD2 technical requirements?
EDIT: I tried my luck with the developers of openbanking project
PS I understand that this question is technically a "questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam"
This question must have a unique and precise answer from a single regulator - the EC, this is not an opinionated answers area.
Here is the UK standard.
https://www.openbanking.org.uk
Also there is a linkedin group to connect developers working on PSD2 and Openbanking with banks, regulators and suppliers here.
https://www.linkedin.com/groups/12069802
I got an answer from the "owner" of the OBP project, I'm posting it verbatim:
Regarding the current status, Open Bank Project API develop branch currently supports OBP API specs 1.2.1 through 3.0.0
We also have an ISO20022 connector (PAIN) for initiating payments.
You can read the OBP specs here:
https://apiexplorersandbox.openbankproject.com/
or use the Swagger:
https://apisandbox.openbankproject.com/obp/v1.4.0/resource-docs/v3.0.0/swagger
or Resource Docs (our own format):
https://apisandbox.openbankproject.com/obp/v1.4.0/resource-docs/v3.0.0/obp
(the Swagger / Resource Doc links can also be found at the bottom of the API Explorer)
Regarding PSD2, PSD2 doesn't explain exactly how countries should comply (e.g. it doesn't define URLs etc.). However, it does say in Article 28 point 3: "Account servicing payment service providers shall also ensure that the dedicated interface uses ISO 20022 elements, components or approved message definitions, for financial messaging".
This is why STET (the recent French standard) uses field names like "PmtTpInf", "InstrPrty", "SvcLvl" and "Cd" etc.
In addtion to the OBP standards mentioned above, we aim to support:
An ISO 20022 version of OBP. This will most likely be requested using a different Mime type on the current OBP URLs and will be implemented as an automatic translation of OBP terms to ISO20022 equivelents (where they exist). We'll probably support ISO20022 short field names and also longer type names (which are verbose but are more self describing).
UK Open Banking standard
STET (French)
Other Country standards.
Thus OBP API will be able to surface multiple standards using one OBP instance and backend connector. It will provide easy to use REST APIs (OBP) and less easy to read ISO20022 interfaces for compliance.
Hope that helps.
p.s. here is STET: https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf
If you are looking for a technical standard that is intended to be applicable across all PSD2 countries, you should check out the Berlin Group spec.
The Open Banking spec is somewhat UK specific, it might be sufficient if you only need to support UK market, or you could extend it to support other products/markets (e.g. SEPA payments).
I've been looking for an answer to this question myself, hoping that I'll find a PSD2-compliant JSON-based answer, rather than have to figure out ISO20022.
I found this brilliant article by Starling Bank saying:
As of November 2017, however, the Open Banking Implementation Entity (OBIE) announced amendments to the scope of Open Banking to broaden out the Open Banking solution to include PSD2 items “in order to deliver a fully compliant PSD2 solution” – which can be read in full here and here.
It seems to me that if Open Banking is designed to be PSD2-compliant and it already delivers detailed specs, then the safest bet here is to simply implement Open Banking specs.
I've also found that viable alternatives to this are:
The Berlin Group's NextGenPSD2 specs, published as a YAML file.
The Stet specs, also published as a YAML file.
The text of PSD2 is here: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32018R0389&from=DE
I found this from here: https://raue.com/en/e-commerce-2/new-eu-regulation-for-electronic-payments-and-online-banking/ which has a helpful summary.
PSD2 is the interface requirement, I don't understand why so many of the responses are about Open Banking, which is just about how to use the interface!
The specs rely a lot on JWTs I found this website very useful if it helps anyone - https://openbankingsdk.com
How can I determine if a CIM/WBEM package e.g. OpenPegasus, OpenWBEM, pyWBEM, SBLIM provide
SMI-S compliant client APIs to develop and management application.
These all are CIM compliant but I could not find out whether SMI-S is supported.
And how can SMI-S client API support be included in a CIM Compliant CIM/WBEM package?
Your question unfortunately is a "given all apples are fruit, how can I verify that the specific piece of fruit I am holding is also an apple?"... it's not an easy question to answer... unless you have a lab full of equipment to test the genome of the fruit before you... or purchased it from a reputable dealer and it came pre-certified as an apple.
CIM is the base protocol.
WBEM is a specification, based on CIM which lays out some additional specifics.
SMI-S is another spec, based on WBEM and laying out a number of additional specifics.
So from the start, OpenPegasus & OpenWBEM are not automatically SMI-S compatible... only through the creation of SMI-S compatible profiles & providers are they can be.
When it comes to determine if a SMI-S provider/api/etc is actually compliant with the specs, that depends on what your requirements are and how much time & money you have to invest.
Like many protocols, it can sometimes be enough to simply see if it works well enough for your purposes and test with different configurations from different vendors along the way... one way to do that is to attend a SNIA plugfest: http://www.snia.org/forums/smi/tech_programs/lab_program
Given that SNIA owns the SMI-S standard, they also have a program for verifying compliance with it: http://www.snia.org/ctp/ (though it like many standard based verification will cost some $$$).
anukalp,
Any client which claims that it supports CIM operations should be able to do the profile discovery.
The clients which I am aware of :- pegasus client, Java client from sblim project are all capable of this.
As a starting point, you should enumerate the RegisteredProfiles in the interop namespace and then follow the CIM_ElementConformsToProfile association to reach the implementation namespace.
Hope this helps.
Taken aback to day when I was confronted about the use of validation code used from the Csla framework. It felt like I was reprimanded for not disclosing the use of the framework to the client.
Is this not the same as using libraries such as jQuery etc?
You absolutely should acknowledge what you're using, IMO.
Some clients may have particularly strict legal requirements (whether for legitimate reasons or not - they're the client, it's not up to you to judge their laywers) and detailing any third party software you're using to create a product for them seems only reasonable.
What reason could you have for not wanting to be open with your client?
This depends on the license of the open source code you are using. Many of them require to acknowledge the use in some credits section, others require you to redistribute the source code, etc. You should read the license and act accordingly.
It depends on the project and the kind of client and whatever contracts you had. However, for a typical consultant delivering code to a customer, I would say no it is very strange that you would be reprimanded for not bothering them with details such as the use of CSLA. That's pretty odd.
It is the same, I have a feeling that you would have been reprimanded for using jQuery as well. There are enterprises that frown upon the use of open source for various reasons.
They boil down to
The type of license and what does it force the user to do
The availability of support in some commercial form
The need to 'share-alike' the results
You should know what's your customer/employer's stance on this. If they don't have a stance, then you have to discuss on a case-by-case basis.
I usually tell people I use a lot of open source and, by seeing the response I get I know the path to follow. If they jump and scream at the mention of open source and the lack of support and whatnot, I just tend to ask for budget to buy commercial components or present good cases as to why the open source version of X is better than the commercial alternatives.
It very much depends on the type of project and the type of client. The real problem here is that you were surprised, which indicates non-alignment of expectations. How did the client motivate its interest in Csla specifically?
If your client needs to know or cares about which technology you use, then you should specify everything as part of the project documentation. If the choices are clearly described, then it is easier to have a discussion about them, if required. Documentation also gives you a way to ask (literally) for 'sign-off', if that is the way you work.
From your question it is not clear whether the problem was the choice of framework, or not having informed the customer.
Even on projects with minimal documentation, if the customer owns the code then I always deliver at least a High-level architecture document that includes the names and exact versions of every software component used, along with a brief description of what it is for and why it was selected. This is also the correct place to address any license issues.