David,

I don’t understand “tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.”

What do you mean by “forward link”, and yes I think we do know where we store links when have inverse-links e.g. validatesRequirement is stored on the test case, and validatedBy on the Requirement. You said this yourself.  

It’s not a new topic. The issue being discussed is knowing which side of the link should store the link. Knowing, for example, that validatesRequirement stored on a test case has an inverse validatedBy that might be stored on a requirement tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

Best regards,

David

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

There seems to be general agreement we can store a “link” on either side given that the “link” has two predicates (one for the subject and then an inverse-link). Also there seems to be some agreement that the inverse-link information would be listed in ResourceShapes, so that a tool might even know what links to query for.

The only point is that IBM-ELM doesn’t currently do it this way. In OPT-IN mode links are stored only on the dependent side. In OPT-OUT they are usually (but not always) stored on both side with the inverseLink.

Link profile work is trying to be inclusive, to define what is required to get as much as possible to integrate with as little effort as required (therefore I softened my position on oauth1.0a)

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

Best regards,

David

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

It’s not a new topic. The issue being discussed is knowing which side of the link should store the link. Knowing, for example, that validatesRequirement stored on a test case has an inverse validatedBy that might be stored on a requirement tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

Best regards,

David

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

Best regards,

David

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

Best regards,

David

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

Best regards,

David

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

Hi

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

regards

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

Hi François-Régis,

Yes the intent is exactly that we want to include as much as possible (and so unfortunately making too many concessions to ELM). I did assume that customer pressure to support OIDC had affected all of us, since everything we do supports both Oauth10a, and also authenticates via OIDC against the customer’s SSO. (which is also the case with ELM). So perhaps, I should have phrased this as a question. I jumped to quickly – sorry.

It may not be a good idea to wait until ELM supports V3 to move away from OAuth1.0a, it is unclear how long that might be. But, also as you say we can’t leave others behind too.

I suggest we wait to see if there is any possibility that ELM work with OIDC. My question has been escalated and hopefully we’ll get an answer soon.

If ELM doesn’t have any support for outgoing OIDC tokens (as described), then we have no options anyway and the chains to OAuth1.0a remain. But if ELM does I’d like us to consider a specification that gives more freedom in this area without excluding those only supporting to OAuth1.0a

Thanks for the clarification.

Cheers,

Ed

I would discourage that for the profiles. I understand that OAuth1.0a is bad… But the idea for the profiles should still be that not only IBM can claim to be compliant! With no support for OAuth1.0a in the profiles, then you exclude all Siemens tools from the conformance, and basically all OSLCv2 compliant implementations… Right after you finally published the v3 saying all v2 is automatically v3-compliant.

That does not feel like the initial intent for these profiles, at least from my point of view.

Yes well this exactly my point and the reason for my questions.

If ELM can we configured to use OIDC without need for external products or extra licenses, I guess we can retire OAuth1! Then anyone using a legacy setup can be told their non-profile-conformant ELM installation can be brought into conformance with just a config change.

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

Ed,

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
3. A combination of both.

Please speak up…

Eran

Ed

Please review the link ownership text

Link ownership

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

Thanks

eran

I would discourage that for the profiles. I understand that OAuth1.0a is bad… But the idea for the profiles should still be that not only IBM can claim to be compliant! With no support for OAuth1.0a in the profiles, then you exclude all Siemens tools from the conformance, and basically all OSLCv2 compliant implementations… Right after you finally published the v3 saying all v2 is automatically v3-compliant.

That does not feel like the initial intent for these profiles, at least from my point of view.

Yes well this exactly my point and the reason for my questions.

If ELM can we configured to use OIDC without need for external products or extra licenses, I guess we can retire OAuth1! Then anyone using a legacy setup can be told their non-profile-conformant ELM installation can be brought into conformance with just a config change.

Yes well this exactly my point and the reason for my questions.

If ELM can we configured to use OIDC without need for external products or extra licenses, I guess we can retire OAuth1! Then anyone using a legacy setup can be told their non-profile-conformant ELM installation can be brought into conformance with just a config change.

If ELM can we configured to use OIDC without need for external products or extra licenses, I guess we can retire OAuth1! Then anyone using a legacy setup can be told their non-profile-conformant ELM installation can be brought into conformance with just a config change.

On 2022-09-28, at 12:36, Gentry, Edward <e.gentry@...> wrote:

Hi François-Régis,

 

Yes OAuth 1.0a would be the fall back position. But if ELM supports OIDC bi-directionally as I’ve described then we can finally leave 1.0a in the dust bin.

 

I had a talk with the IBM team a month ago and there heard language that might indicate that ELM might sign outgoing requests with OIDC tokens. It was not convenient, at that time, to explore it further, and to determine if it was true and these were token from the external authentication provider and not just JAS/Liberty.

 

My point is that if we have the opportunity to free ourselves from 1.0a shackles we should do it.

 

Otherwise, then exactly as you suggest. 

 

Cheers,

 

Ed

 

From: François-Régis Jaunatre <frjaunatre@...> 
Sent: Mittwoch, 28. September 2022 11:44
To: oslc-op@...; Gentry, Edward <e.gentry@...>; Jim Amsden <jamsden@...>; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Authentication for OSLC Link Profile

 

Sie erhalten nicht oft eine E-Mail von frjaunatre@.... Erfahren Sie, warum dies wichtig ist

Hello Ed,

 

I would probably make this a lot simpler here.

 

We are trying to build profiles that “work out of the box”. With that in mind, OAuth1.0a must be a requirement and OAuth2 should be implemented with the future (and better security) in mind.

Then we need to explicit for a client how to determine if OAuth2 is available, in which case he should use OAuth2, or else fallback to OAuth1.0a.

 

Only thing then IMO is the way ELM (as a client) determines whether the other side supports OAuth2 / OIDC, if any. That’s what most needs to be clarified. And if that’s by reading some IBM-only property “jd:jsaSsoEnabled” in the rootservices, then doing x, y and z… well that’s all fine. It just needs to be clarified and documented in the profiles.

Best regards, Sincères salutations,

François-Régis Jaunatre
OSLC Connect for Windchill & OSLC Lab
<image001.png>

Check out OSLC Connect for Jira & OSLC Connect for Windchill

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: 28 September 2022 10:21
To: Jim Amsden <jamsden@...>; oslc-op@...; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>
Subject: [oslc-op] Authentication for OSLC Link Profile

 

Hello All,

 

After further consideration of the authentication section for our OSLC Link Profile, I would like to suggest that someone from IBM needs to write this. Because, while I do have plenty of experience with authentication and OSLC, I don’t know the details of IBM-ELM’s implementation. I requested an audience with John Vasta, to remedy this but this was denied. Perhaps IBMers might find it easier to get a few moments of his time.

 

At issue here is to what degree IBM-ELM supports OIDC. In my view if IBM-ELM  supported OIDC properly (as I’ll describe below), then the authentication section could be short and simple.

 

Since IBM-ELM 7.0.1 (I think), when configured with JAS – and using an external OIDC authentication provider - it was possible to send an incoming  request authenticated with OIDC to IBM-ELM (e.g. a resource GET). The problem was that outgoing requests from IBM-ELM (e.g. reading rich hovers, compact rendering, and TRS feeds) still used OAuth 10a. I don’t know of this is still the case.

 

So my questions to John Vasta are:

 

Regarding IBM-ELM support of OIDC – especially when using an external OIDC authentication provider (e.g. keycloak, or Ping) in a the typical SSO configuration

 

1. Are HTTP requests received by IBM-ELM supported which have bearer tokens from the external OIDC authentication provider (assuming properly configured with JAS) – This should be YES since 7.0.1 or so.
2. Are HTTP requests leaving IBM-ELM signed by the external OIDC authentication provider (e.g. keycloak or ping) and not just JAS/Liberty. - As far as I know this is NO

 

Regarding usage of functional users (aka technical users)

 

If the answer to 2 is NO then:

It is now well established that in some cases outgoing REST calls from IBM-ELM expect a 2-legged OAuth 1.0a flow (the functional equivalent to OIDC’s Client Credential Grant). And it seems that there are different implementations of this: LDX/LQE have allow for separate client keys and secrets, and GCM expects a 2-legged flow using the client keys and secrets from the friend when the oauth_token is blank. 

 

1. Can we have a comprehensive understanding of where and how IBM-ELM uses outgoing 2-legged OAuth 10a flows.

 

 

If the answer to 2 is YES then:

              Are the user-ids (as available from the OIDC JWT) available in IBM-ELM for these functional users?

              

 

If IBM-ELM can’t sign its outgoing requests with the external OIDC provider, then probably the simplest solution is to continue to require bi-directional OAuth 1.0a. In my view this is the single biggest obstacle to OSLC.

 

Cheers,

 

Ed

 

Ed Gentry 
Product Owner

e.gentry@... | +49 0172 8867789 | Per Microsoft Teams anrufen

 

<image002.png>

 

MID GmbH | Kressengartenstr. 10 | 90402 Nürnberg
Tel.: +49 911 968360 | www.mid.de 
Sitz des Unternehmens: Nürnberg Handelsregister: Amtsgericht Nürnberg HRB Nr. 21108 
Vorsitzender der Geschäftsführung: Dr. Martin Müller Geschäftsführer: Andreas Ditze
 .
<image003.png>  <image004.png> 

 

Hello All,

After further consideration of the authentication section for our OSLC Link Profile, I would like to suggest that someone from IBM needs to write this. Because, while I do have plenty of experience with authentication and OSLC, I don’t know the details of IBM-ELM’s implementation. I requested an audience with John Vasta, to remedy this but this was denied. Perhaps IBMers might find it easier to get a few moments of his time.

At issue here is to what degree IBM-ELM supports OIDC. In my view if IBM-ELM  supported OIDC properly (as I’ll describe below), then the authentication section could be short and simple.

Since IBM-ELM 7.0.1 (I think), when configured with JAS – and using an external OIDC authentication provider - it was possible to send an incoming  request authenticated with OIDC to IBM-ELM (e.g. a resource GET). The problem was that outgoing requests from IBM-ELM (e.g. reading rich hovers, compact rendering, and TRS feeds) still used OAuth 10a. I don’t know of this is still the case.

So my questions to John Vasta are:

Regarding IBM-ELM support of OIDC – especially when using an external OIDC authentication provider (e.g. keycloak, or Ping) in a the typical SSO configuration

1. Are HTTP requests received by IBM-ELM supported which have bearer tokens from the external OIDC authentication provider (assuming properly configured with JAS) – This should be YES since 7.0.1 or so.
2. Are HTTP requests leaving IBM-ELM signed by the external OIDC authentication provider (e.g. keycloak or ping) and not just JAS/Liberty. - As far as I know this is NO

Regarding usage of functional users (aka technical users)

If the answer to 2 is NO then:

It is now well established that in some cases outgoing REST calls from IBM-ELM expect a 2-legged OAuth 1.0a flow (the functional equivalent to OIDC’s Client Credential Grant). And it seems that there are different implementations of this: LDX/LQE have allow for separate client keys and secrets, and GCM expects a 2-legged flow using the client keys and secrets from the friend when the oauth_token is blank.

1. Can we have a comprehensive understanding of where and how IBM-ELM uses outgoing 2-legged OAuth 10a flows.

If the answer to 2 is YES then:

              Are the user-ids (as available from the OIDC JWT) available in IBM-ELM for these functional users?

If IBM-ELM can’t sign its outgoing requests with the external OIDC provider, then probably the simplest solution is to continue to require bi-directional OAuth 1.0a. In my view this is the single biggest obstacle to OSLC.

Cheers,

Ed

Ed Gentry
Product Owner

e.gentry@... | +49 0172 8867789 | Per Microsoft Teams anrufen

MID GmbH | Kressengartenstr. 10 | 90402 Nürnberg
Tel.: +49 911 968360 | www.mid.de
Sitz des Unternehmens: Nürnberg Handelsregister: Amtsgericht Nürnberg HRB Nr. 21108
Vorsitzender der Geschäftsführung: Dr. Martin Müller Geschäftsführer: Andreas Ditze
 .
   

Hi Ed,

Apologies if I’ve got the names wrong here, but isn’t the OSLC spec called Config Mgmt? And the IBM software capability is called Global Configurations?

Not meaning to be a pedant, just important to be clear I think.

I guess I’ve also not been clear on some other points – please see response to Eran below.

Patrick

So what is your policy for link storage?

Which side stores the link?

Thanks

Eran

With PTC, always the tool that is used to create the link – the client – stores the link, and only that tool. We have considered creating “backlinks” – i.e. a link on both sides, but have concerns on how these would be maintained over time. (For example when a linked object get deleted, or say a package full of linked objects are deleted in one operation. It would require the backlinks to also be deleted in the external tool(s) – which probably wouldn’t scale)

Personally I feel having a “centralized link repository” that all lifecycle tools can connect to, where all links are stored and can be accessed, makes a lot of sense architecturally. But practically speaking it would be challenging to implement, especially if connecting tools are from different vendors.

Regards,

Patrick

Hi Patrick,

As I said I’m really glad to see other vendors joining the conversation.

How we make links really does depend on whether we are in a global configuration aware environment or not. In a global configuration aware environment we don’t need to make back  link, and indeed should make them because the system becomes very brittle and reuse becomes difficult.

Applications should not be forced to create backlinks just because some other applications may not understand or support global configurations. (Recall that global configurations are also an OSLC specification).

I really don’t see any other solution than to have two modes.

Cheers,

Ed